Re: [jira] Commented: (SHINDIG-203) Extract Interfaces from the Social Model to make it easier to Implements Social Containers

[Ian Boston <ie...@tfd.co.uk>]

Ok, no worries, (and no rush on my part) its not too much effort for  
me to keep it updated at the moment. Let me know if you want it upto  
a particular revision.
Ian



On 5 May 2008, at 07:59, Cassie wrote:

> --000e0cd29d344e4693044c764643
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> 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) <ji...@apache.org>  
> 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 automaticall