Re: updates to proposal (was: Codebases and Tidbits and Moving towards a proposed vote)

Maybe focusing on describing scenarios/requirements instead of
focusing on technology itself would make things clear ?
While I'm still planning to spend some time reviewing the current
version of the proposal tonight, some comments on the two questions
below.

On Wed, Jul 16, 2008 at 4:46 PM, Angela Cymbalak <[email protected]> wrote:
> Our thought was to use both Sling and a WS interface for slightly different
> purposes.
>
> The thought is to use Sling for the main default viewer.  However, we want
> to expose everything as a Web service for two reasons:
>
> 1. Allow those who want a different form of display to interact with the WS.
>  This would allow for really any additional type of interface to be written
> (i.e. flex, ajax, etc.)

Here, I think that Atom Feeds might be a good idea as well. See the
concept described in [1]. We could even start doing gallery as a
composition of multiple remote albums (e.g couple friends that took
pictures from a given event and posted the pictures in different photo
websites). Contradicting myself, and talking a little about
technology, one good thing about Tuscany (and it's bindings) is that
it makes you focus on the the business requirements/logic, and leave
the communication infrastructure to a later point, so you have your
service exposed as webservices, feeds or jsonRPC transparently.

[1] http://www.google.com/uds/solutions/slideshow/

>
> 2. Allow other services to interact with the gallery.  The specific example
> we were thinking of are the companies that allow you to order things with
> photos on them.  We'd like to be able to allow interaction with these
> services.
>

I haven't looked into these services yet, but REST access to the
pictures could give the same results.

> Noel, do I have all that correct?
>
> Angie
>
> At 02:29 PM 7/16/2008, Martin Cooper wrote:
>>
>> On Wed, Jul 16, 2008 at 6:12 AM, Roland Weber <[email protected]> wrote:
>>
>> > Hi Angie,
>> >
>> >  But I'm still not happy with the sections on
>> >>> "Initial Goals"/"High Level Design" and "Relationships
>> >>> with Other Apache Products".  This has to do with all
>> >>> the open design questions in the proposal. It is important
>> >>> to document such questions and the decisions, but that
>> >>> does not belong into the proposal. [...]
>> >>>
>> >>
>> >> I can go either way.  As long as they are documented somewhere.  I
>> >> think
>> >> the reason that they ended up there is that we currently don't have
>> >> anywhere
>> >> else to document them.
>> >>
>> >
>> > We have this mailing list, which is archived:
>> > http://mail-archives.apache.org/mod_mbox/incubator-projects/
>> > Once the podling gets started, we can put such
>> > stuff up on a wiki or web page.
>> >
>> >
>> >>  2. Define a roadmap for the "Inital Goals" section: [...]
>> >>>
>> >>
>> >> Not sure how to word that well.  It could be the fever talking...
>> >>
>> >
>> > I can have a stab at it tomorrow. I'm usually
>> > quite good with words, just wanted to discuss
>> > the contents first.
>> >
>> >  The reason why I'm not jumping ahead with this is
>> >>> that I am not sure yet whether my understanding of
>> >>> the high level design is the current consensus.
>> >>>
>> >>
>> >> I think that your understanding is my understanding.  It is what
>> >> Luciano
>> >> has been coding toward, I think, and what Noel and I have discussed.
>> >>
>> >
>> > I'm still unclear about the role of Sling in this.
>> > Is it just a "yeah, we *could* use that all right",
>> > or is it really the intention "our UI will be built
>> > on Sling"? In the latter case, there will be a
>> > web service API for accessing the repository, and
>> > a UI component that uses JCR directly (unless I am
>> > mistaken about Sling). That's not a problem, but
>> > something that people should be aware of.
>>
>>
>> Indeed. We should be very cautious about exposing a web services interface
>> if we're not actually going to use it ourselves. It would be all too easy,
>> that way, to come up with an API that doesn't actually work for real-world
>> applications.
>>
>> I'd prefer to see us either build on Sling initially and look at a web
>> services API later, or build a UI that sits on web services initially and
>> perhaps look at Sling later. I'm not sure that tackling both right off the
>> bat would be realistic. That's IMHO, anyway.
>>
>> --
>> Martin Cooper
>>
>>
>>
>> >
>> >  Didn't mean to exclude you from the community!  I changed it to include
>> >> architectural direction as well.
>> >>
>> >
>> > Thanks :-)
>> >
>> >  I did make mention of the Roller discussions when I updated the
>> > proposal
>> >> but didn't include the links.
>> >>
>> >
>> > That's fine.
>> >
>> >  Does anyone else have suggestions?  Feel free to update the proposal!
>> >>
>> >
>> > For a timeline, I suggest to finalize the proposal
>> > this week. Then we can call for a vote either this
>> > weekend or at the beginning of the next week. I am
>> > available to engage in discussions next week.
>> >
>> > Thoughts, anyone?
>> >
>> > cheers,
>> >  Roland
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [email protected]
>> > For additional commands, e-mail: [email protected]
>> >
>> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/