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