Okay - if someone can sanity check this: https://issues.apache.org/jira/browse/SHINDIG-453 then this thread can be resolved.
- Cassie On Tue, Jul 15, 2008 at 5:19 PM, Cassie <[EMAIL PROTECTED]> wrote: > Alright then - I'll create a jira and add a patch for doing this. > Thanks everyone! > > - Cassie > > > > On Tue, Jul 15, 2008 at 4:08 PM, David Primmer <[EMAIL PROTECTED]>wrote: > >> On Tue, Jul 15, 2008 at 10:29 AM, Cassie <[EMAIL PROTECTED]> wrote: >> > I don't really support having both versions around in Shindig forever >> > because I think it would confuse new users deciding which one to choose >> and >> > would be more work than its worth for this project to maintain. (2 sets >> of >> > bugs, patches, mail threads, design decisions, etc) However, anyone can >> > build an OpenSocial container in whatever way they like - Shindig is >> just >> > one impl choice (of course we hope to be the best :) >> > >> > That being said, it looks like the general consensus here is moving to >> > option #2 (the "dataservice" package). >> > Should we move forward with this? Or do we want to discuss this more? >> > >> > David - do you think this accurately reflects this thread? You stated >> that >> >> yep >> >> > you would continue working on this code. Does everyone here think that >> David >> > moving the code to another repository is the right choice? Or should we >> go >> > with Ian's option and just leave both be? >> >> I say svn delete them and figure out where you need to re-add >> dependencies for the things that you'd get in abdera one at a time as >> they're needed. Remove it all, including the enum with the named >> routes. >> >> oh, and check in dirk's servlet filter auth patch at move token >> checking out of the handler code... ;-) >> >> davep >> >> > >> > Thanks for all of the comments! >> > >> > - Cassie >> > >> > >> > >> > On Tue, Jul 15, 2008 at 3:47 AM, Ian Boston <[EMAIL PROTECTED]> wrote: >> > >> >> David, >> >> I am sorry that I didn't reply to the your message on Friday, I went >> >> offline for a few days, just got back online today. >> >> >> >> Firstly I should apologize, I didn't want to pass any comment on the >> >> contribution of any part of the implementation, because I think that >> both >> >> are extremely valuable, and represent many hours of thought and work. >> >> >> >> I also think that Abdera is a really strong framework that is ideally >> >> suited to this type of work, especially in the Atom area, and will be >> >> invaluable to a full blown SNS which needs to support more than just >> OS. >> >> >> >> What I was trying to say, ineptly, was that I felt we needed to be >> careful >> >> that any bindings inside Shindig don't prevent others already using a >> >> version of Abdera (or any other framework) from continuing to use it. >> Having >> >> options allows that to happen. >> >> >> >> So to rephrase my original opinion, both approaches would be great and >> >> would allow users of shindig to decide which one they wanted to use >> provided >> >> a) there is resource in the shindig community to support both, and >> >> b) they can easily be backed off the same underlying service API's >> >> >> >> It sounds like you are willing to do some of that work... so you get my >> >> vote (not that I should have one for triggering such a long thread.) #2 >> also >> >> gets my vote because it generates choice and has resource prepared to >> work >> >> on it. >> >> All IMHO, >> >> >> >> Sorry everyone, I'll remember to wait to let others confirm what I am >> >> thinking next time. >> >> Ian >> >> >> >> >> >> >> >> >> >> On 15 Jul 2008, at 02:46, David Primmer wrote: >> >> >> >> On Sat, Jul 12, 2008 at 12:40 PM, Kevin Brown <[EMAIL PROTECTED]> >> wrote: >> >>> >> >>>> There's a pretty good recent analogy for this issue, which was the >> Linux >> >>>> task scheduler. Two very capable implementations were developed, but >> the >> >>>> one >> >>>> that was chosen was done so because the people who worked on it were >> >>>> highly >> >>>> dedicated to the task. >> >>>> >> >>>> I think the same criteria needs to be applied here. For people who >> are in >> >>>> favor of the 'new' code, are you willing to accept the burden of >> >>>> maintenance, patches, and support? Are you going to continue doing >> that >> >>>> even >> >>>> if you change employers? for people in favor of the abdera code -- I >> ask >> >>>> the >> >>>> same. >> >>>> >> >>>> That's really what this boils down to. If both implementations get >> the >> >>>> job >> >>>> done correctly, then the decision for which one to use is simply a >> matter >> >>>> of >> >>>> determining who's going to ensure success of the component. If we >> only >> >>>> have >> >>>> one person who's going to work on one side and 10 people on the >> other, >> >>>> then >> >>>> the choice is obvious. >> >>>> >> >>> >> >>> Another eminently reasonable point from Kevin. Although I don't think >> >>> you can always get a promise for future development in any open source >> >>> project, we do have commitments from some pretty big companies to work >> >>> on this. I really hope that the amount of contributions outside of >> >>> Google employees increases going forward in the java api server. It's >> >>> disappointingly lopsided so far, but maybe the OS Foundation will make >> >>> it safer for others to devote valuable developer hours to it. I'm >> >>> still motivated to work on an Abdera-based approach, and will probably >> >>> carry it on in some other repository. My interest has always been more >> >>> in the data portability possibilities that are appearing via AtomPub, >> >>> as well as the extensibility of the OpenSocial framework. It has a lot >> >>> of potential as a general purpose development platform and there's a >> >>> lot of cutting-edge stuff in there that will be useful to more than >> >>> just social networks. >> >>> >> >>> davep >> >>> >> >> >> >> >> > >> > >
