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) <[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 automaticall
