On Tue, May 13, 2008 at 5:23 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
> I am not certain if this helps but here goes, > > If you are talking about the PersonService, ActivityService in the > social-ap > etc then SHINDIG-203 and SHINDIG-204 might help > > If you are not, then I have misread, sorry, ignore the rest. > > 203 abstracts the interface between the social-api implementation and the > sample container core (for the social part) so they could be separated. The > patch was good a while back but would probably need a refresh. > > 204 provides a DB based impl of PersonService (for most of the major > relational db's), that although is probably no real use as it stands, is > slightly closer to a read/write imple. This is not fully tested or complete, > but the datamodel has some reasonably extensive unit tests against it. > > Having separated out with 203, it would not be too hard to put the > samplecontainer and db impl of the social api services into a separate jar > that would be guice constructed in the server web.xml..... if that makes any > sense. As always, having suggested something.... if its what you want then I > would be happy to help on all or part of it. Having it as a separate artifact (java/social-api-db or something) would be ideal. This would allow us to publish the artifact separately and not put arbitrary requirements on the core package that people may or may not use. > > Ian > > > > > On 13 May 2008, at 09:31, Kevin Brown wrote: > > On Tue, May 13, 2008 at 12:56 AM, Cassie <[EMAIL PROTECTED]> wrote: > > > > For the java side, if we could somehow move the samplecontainer java > > > code and the serving of the javascript folder out into the server pom > > > then that would be what you wanted, right Kevin? > > > > > > > > > No, I was actually just thinking that it doesn't make a lot of sense to > > have > > a completely throwaway implementation packed into the main code base. On > > the > > other hand, it's not clear to me that there's any "good" way to provide > > default implementations of the data handlers that would actually be > > useful. > > > > That was really just an aside though. The main issue was resolved by > > replacing the dependency on RemoteContentFetcher on a simpler dependency > > directly on the commons http client. > > > > > > > > > > > > (not that I know how to do that, but we could file a bug against > > > ourselves and fix it later.) > > > > > > I actually don't think this is a super urgent thing to fix. The > > > samplecontainer java code is pretty much stagnant and won't be getting > > > any new dependencies. The benefits of having a container that actually > > > does something by default pretty much outweigh any drawbacks in my > > > mind. And if the js code gets more complex I don't think that will > > > bother anybody either.. its just js and easy to exclude from real > > > deployments. > > > > > > - Cassie > > > > > > > > > On Tue, May 13, 2008 at 8:29 AM, Santiago Gala < > > > [EMAIL PROTECTED]> > > > wrote: > > > > > > > On Tue, May 13, 2008 at 5:22 AM, Brian Eaton <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > On Mon, May 12, 2008 at 3:57 PM, Kevin Brown <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > > > > > > I was actually just going to suggest that they simply be > > > > > > separate > > > > > > > > > > > artifacts, > > > > > > > not anything as involved as the "sub-projects" under jakarta and > > > > > > > > > > > the like. > > > > > > > > > > > > +1. The gadget container and gadget rendering server are joined > > > > > at > > > > > the hip, it makes sense to have them both under the shindig > > > > > umbrella. > > > > > > > > > > > > > > +1 with having them as separate artifacts. > > > > > > > > Re: the comparison with jakarta, I was not implying moving code out > > > > of > > > > shindig, just explaining why there is a cultural bias against making > > > > too many separate departments in the same project. If subprojects > > > > are > > > > created, they would be kept here. > > > > > > > > The use case of Chris is closer to give some trouble in this regard: > > > > Developing a full fledged container, with "concrete" implementation > > > > of > > > > the APIs, is beginning to have a non-100% overlap with the shindig > > > > charter. Further, a number of people involved in shindig are > > > > maintaining private (or at least "uninteresting" for outsiders) > > > > interfaces to their systems, so they would not likely be interested > > > > at > > > > all in having a sample implementation, ... > > > > > > > > I guess that, for the moment, the approach that Chris has taken, > > > > i.e. > > > > open an outside project and see who joins, is the best. We can > > > > consider getting the code back into Apache as needed in the near > > > > future. > > > > > > > > Regards > > > > Santiago > > > > > > > > > > > >
