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 > >>> > >> > >> > > >
