updates to proposal (was: Codebases and Tidbits and Moving towards a proposed vote)
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
updates to proposal (was: Codebases and Tidbits and Moving towards a proposed vote)
by Angela Cymbalak
::
Rate this Message:
This makes for a long email now, combining the two threads but it may
be easier to read. >Regarding the proposal, I have made some updates. Thanks for making the updates! >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. Does anyone else have an opinion? >2. Define a roadmap for the "Inital Goals" section: [...] Not sure how to word that well. It could be the fever talking... >3. Update the "Relationships" section: > >[...] >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 used what you had to update the Wiki page. I didn't mention the middleware components. I wasn't sure when I was first writing the proposal what that section was really supposed to be so I just listed everything. >Initial committers should list themselves. [...] Thanks for clarifying. Please list yourselves! >[...] >"Meritocracy" - Every person who is currently part >of the community has code that they have developed >yet are willing to rewrite for the good of the project. > >I feel excluded from the community here. Suggestions? Didn't mean to exclude you from the community! I changed it to include architectural direction as well. >"Orphaned Projects" > >I would have gone for something like "We're just starting, there >is a high risk", but that's a matter of personal preference :-) I guess blatant honesty is best sometimes. :-) Done. >[...] >"Relationships with Other Apache Products" > >>I know that there are some following this discussion because of the >>technologies being used and not the problem space or project necessarily. > >That should be mentioned in this section. Some of the >existing references are superfluous though. Or should >we really tie ourselves to Tomcat instead of writing >something that runs in any Servlet/JSP container? Done and no. >I found this thread, where you said AJAX and somebody >else mentioned JavaScript - is that what you meant? >http://www.nabble.com/photo-gallery-for-Roller-td17087810s12275.html > >Since there were discussions with Roller, we should >mention that in the proposal, and also explain why >we're not asking Roller to become the sponsor. There was also http://www.nabble.com/mentor-needed-and-proposal-for-photo-gallery-td17214136s12275.html where the entire discussion just dropped. Not my best display of perseverance. I did make mention of the Roller discussions when I updated the proposal but didn't include the links. Does anyone else have suggestions? Feel free to update the proposal! Angie --------------------------------------------------------------------- To unsubscribe, e-mail: projects-unsubscribe@... For additional commands, e-mail: projects-help@... |
|
|
Re: updates to proposal (was: Codebases and Tidbits and Moving towards a proposed vote)
by Roland Weber
::
Rate this Message:
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. > 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: projects-unsubscribe@... For additional commands, e-mail: projects-help@... |
|
|
Re: updates to proposal (was: Codebases and Tidbits and Moving towards a proposed vote)
by Martin Cooper-2
::
Rate this Message:
On Wed, Jul 16, 2008 at 6:12 AM, Roland Weber <ossfwot@...> 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: projects-unsubscribe@... > For additional commands, e-mail: projects-help@... > > |
|
|
|
|
|
Re: updates to proposal (was: Codebases and Tidbits and Moving towards a proposed vote)
by Luciano Resende
::
Rate this Message:
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 <a.cymbalak@...> 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 <ossfwot@...> 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: projects-unsubscribe@... >> > For additional commands, e-mail: projects-help@... >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: projects-unsubscribe@... > For additional commands, e-mail: projects-help@... > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: projects-unsubscribe@... For additional commands, e-mail: projects-help@... |
|
|
Re: updates to proposal (was: Codebases and Tidbits and Moving towards a proposed vote)
by Roland Weber
::
Rate this Message:
Hello Luciano,
Luciano Resende wrote: > Maybe focusing on describing scenarios/requirements instead of > focusing on technology itself would make things clear ? Good point. I started by adding an intro to the "Proposal" section, trying to explain what a photo gallery software is supposed to do. I also explicitly mentioned the web interface, to distinguish it from a desktop application for managing one's photos on a PC. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: projects-unsubscribe@... For additional commands, e-mail: projects-help@... |
|
|
|
|
|
Re: updates to proposal (was: Codebases and Tidbits and Moving towards a proposed vote)
by Luciano Resende
::
Rate this Message:
On Thu, Jul 17, 2008 at 12:12 PM, Angela Cymbalak
<a.cymbalak@...> wrote: > >> > 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/ > > This may be what your last sentence above is saying. Couldn't we expose the > information as a Web service using Tuscany and then write something that > would translate the info from the Web Service into a an Atom Feed? That > way, while it is a good idea, it can be dealt with at a later time? This would be very transparent in Tuscany, most of the times, you just need to say that your component is using <binding.ws> or <binding.atom> or <binding.jsonrpc> or all of the above. > >> > 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 has more experience with these services than I do but from our > discussion, I think that more information was needed at one time than what > the REST interface would provide. > > Angie > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: projects-unsubscribe@... > For additional commands, e-mail: projects-help@... > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: projects-unsubscribe@... For additional commands, e-mail: projects-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
