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.
