You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Cassie <do...@apache.org> on 2008/05/05 08:59:36 UTC
Re: [jira] Commented: (SHINDIG-203) Extract Interfaces from the
Social Model to make it easier to Implements Social Containers
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 automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Re: [jira] Commented: (SHINDIG-203) Extract Interfaces from the Social Model to make it easier to Implements Social Containers
Posted by 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