I think this is a good and necessary change (you convinced me by email long ago) and will commit it soon. I've just been enjoying ascension day + svn commit has been all screwy lately.
So, continuing sounds good! - Cassie On Sat, May 3, 2008 at 6:32 PM, Ian Boston (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594008#action_12594008] > > Ian Boston commented on SHINDIG-203: > ------------------------------------ > > A question, > > Should I continue with this patch ? > its getting a bit big at 220K. > > > Extract Interfaces from the Social Model to make it easier to Implements > Social Containers > > > ------------------------------------------------------------------------------------------ > > > > Key: SHINDIG-203 > > URL: https://issues.apache.org/jira/browse/SHINDIG-203 > > Project: Shindig > > Issue Type: Improvement > > Components: RESTful API (Java) > > Reporter: Ian Boston > > Attachments: SHINDIG-203-3.patch > > > > > > Currently the PersonService and other API's in the > org.apache.shindig.social package contain concrete classes in the form of > Pojos to represent the model. Although this is fine, it does limit the > implementation strategy to those methods that can operate on PoJos by > reflection and building the pojos. For some this is Ok, where there use > GCLib or ApsectJ to enhance the Pojos so avoiding excessive Object GC > activity, but for those more direct ORM implementations, that already use > class extension and a method to make the persistence simpler, concrete > classes in the model make it impossible to implement the social model > storage. > > The alternative is to copy the object from the storage into the model, > and or add caching outside the storage space. This is quite a lot of code to > do property, will replicate a significant amount of ORM functionality and > will have an impact on the GC as more objects will be created and destroyed > during each request cycle. > > Converting the API to interfaces (containing the necessary Enums) will > enable any implementation strategy to work (including things like > javax.jcr.Node ) and is minimal impact on those that want a Pojo, since they > can very quickly implement their own Pojos. It will also prevent the > consumer of the API creating object instances and assuming that they will be > saved. > > I will attach a patch in a moment, and add a related implementation of > the Storage layer that uses interfaces. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
