You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Ian Boston (JIRA)" <ji...@apache.org> on 2008/04/21 14:13:21 UTC
[jira] Created: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
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
Reporter: Ian Boston
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] Created: (SHINDIG-203) Extract Interfaces from the Social Model to make it easier to Implements Social Containers
Posted by sa...@wipro.com.
HI ALL
It very nice to see the progress of OpenSocial .
Can anybody help me from where I can get details of OpenSocial Gateway server .
cheers
sandeep dhaiya
“Dream as if you'll live forever, live as if you'll die today.”
-----Original Message-----
From: Ian Boston (JIRA) [mailto:jira@apache.org]
Sent: Monday, April 21, 2008 5:43 PM
To: shindig-dev@incubator.apache.org
Subject: [jira] Created: (SHINDIG-203) Extract Interfaces from the Social Model to make it easier to Implements Social Containers
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
Reporter: Ian Boston
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.
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
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
Re: [jira] Commented: (SHINDIG-203) Extract Interfaces from the
Social Model to make it easier to Implements Social Containers
Posted by Cassie <do...@apache.org>.
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.
>
>
[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-203:
-------------------------------
Attachment: social-api-model-interfaces2.patch
Updated Patch created against r652401
> 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
> Reporter: Ian Boston
> Attachments: social-api-model-interfaces2.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.
[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-203:
-------------------------------
Attachment: (was: social-api-model-interfaces.patch)
> 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
> Reporter: Ian Boston
> Attachments: social-api-model-interfaces2.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.
[jira] Resolved: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cassie Doll resolved SHINDIG-203.
---------------------------------
Resolution: Fixed
Assignee: Cassie Doll
> 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
> Assignee: Cassie Doll
> Attachments: SHINDIG-203-3.patch, SHINDIG-203-4.patch, SHINDIG-203-non-functioning.patch.gz
>
>
> 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.
[jira] Commented: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Vincent Siveton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593515#action_12593515 ]
Vincent Siveton commented on SHINDIG-203:
-----------------------------------------
Definitely agree with Ian to use interfaces, since Shindig is a Java impl of opensocial specs. I guess these interfaces should be in the social-api project and Sindig impl elsewhere
> 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
> Reporter: Ian Boston
> Attachments: social-api-model-interfaces.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.
[jira] Commented: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595702#action_12595702 ]
David Primmer commented on SHINDIG-203:
---------------------------------------
i've added this to reviewboard http://metzby.dyndns.info/r/24/ (it's a biggie and takes a while to load) but it's useful since this is such a large patch. I hope we can keep discussing this.
> 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.
[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-203:
-------------------------------
Attachment: SHINDIG-203-4.patch
Update to patch, at 656491
NB this is not the same patch, at the moment as it on the review board, but there are only minor changes to make it work against trunk at the above revision. There are no functional changes.
> 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, SHINDIG-203-4.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.
[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-203:
-------------------------------
Attachment: social-api-model-interfaces.patch
Patch to extract interfaces from the social model pojos and abstract the current class extension model, to make it possible for other storage implementation strategies
> 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
> Reporter: Ian Boston
> Attachments: social-api-model-interfaces.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.
[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-203:
-------------------------------
Attachment: SHINDIG-203-non-functioning.patch.gz
Patch updated to SVN r666336
However,
The JSON serialization binds direct to the concrete classes which a) need to be bound to in the social-api impl, and b) need to be mentioned in parameterised constructors to ensure that the serializer is given the correct construction information.
So,
An API on the services with no concrete classes will not work at the moment. The mechanism of creating classes on json-bean needs to bind to factories on non-impl specific classes. Since this area is currently under review, this patch does not work, and is only a snapshot. (there are also some fornatting errors)
> 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, SHINDIG-203-4.patch, SHINDIG-203-non-functioning.patch.gz
>
>
> 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.
[jira] Closed: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston closed SHINDIG-203.
------------------------------
Yes, all looks good, I cant see anything missing, thank you.
Although its not that important it might be clearer to separate the package containing the interfaces from the package containing the implementations. It would also make it easier to ensure correct binding from consumers of the API, and make it possible to bundle in things like OSGi in the future.
> 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
> Assignee: Cassie Doll
> Attachments: SHINDIG-203-3.patch, SHINDIG-203-4.patch, SHINDIG-203-non-functioning.patch.gz
>
>
> 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, will fix.
Ian
On 1 May 2008, at 13:49, Vincent Siveton (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/SHINDIG-203?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=12593528#action_12593528 ]
>
> Vincent Siveton commented on SHINDIG-203:
> -----------------------------------------
>
> Personally, I think that interfaces *should* have Javadoc (since
> they are public) with specs references and no abstract key word.
> Also, take care about the code formatting (tab vs space)
>
>> 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
>> Reporter: Ian Boston
>> Attachments: social-api-model-interfaces2.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.
>
[jira] Commented: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Vincent Siveton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593528#action_12593528 ]
Vincent Siveton commented on SHINDIG-203:
-----------------------------------------
Personally, I think that interfaces *should* have Javadoc (since they are public) with specs references and no abstract key word.
Also, take care about the code formatting (tab vs space)
> 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
> Reporter: Ian Boston
> Attachments: social-api-model-interfaces2.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.
[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Brown updated SHINDIG-203:
--------------------------------
Component/s: RESTful API (Java)
> 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: social-api-model-interfaces2.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.
[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-203:
-------------------------------
Attachment: (was: social-api-model-interfaces2.patch)
> 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.
[jira] Commented: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606514#action_12606514 ]
Cassie Doll commented on SHINDIG-203:
-------------------------------------
Alright, I used guice to take care of the json bean converter issue so everything should be cleanly separated now.
Please let me know if I missed anything and I'm very sorry this took so long.
> 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, SHINDIG-203-4.patch, SHINDIG-203-non-functioning.patch.gz
>
>
> 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.
[jira] Commented: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social
Model to make it easier to Implements Social Containers
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-203:
-------------------------------
Attachment: SHINDIG-203-3.patch
Added javadoc to all the interfaces with links back to the opensocial doc where appropriate
> 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.