You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Chris Geer <ch...@cxtsoftware.com> on 2012/05/25 22:54:42 UTC
Modularization
To prod along the conversation about modularization and architecture I
wanted to pick one thing and try and talk through it before moving onto
bigger things. Right now Rave has a core data model defined in
org.apache.rave.portal.model which are all concrete JPA classes. To support
pluggable persistence layers we will need to migrate the definitions to
interfaces and move the JPA implementations to a JPA module. Assuming that
is an agreed upon task I have a couple questions:
1) Has any of this been done as part of the JCR activity? Is that still in
progress?
2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
OpenSocial is the only one so far that defines a backend data structure as
far as I know. With that in mind, does it make sense to consider using the
Shindig data interfaces instead of rolling our own and having to translate
between org.apache.rave.portal.model.Person and
org.apache.shindig.social.opensocial.model.Person? Do we anticipate
non-OpenSocial data models that compete with the OpenSocial one?
Chris
SPIs (was Re: Modularization)
Posted by Scott Wilson <sc...@gmail.com>.
(Moving this over to the Wookie-dev list)
On 28 May 2012, at 20:33, Ate Douma wrote:
> On 05/25/2012 10:54 PM, Chris Geer wrote:
>> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>> OpenSocial is the only one so far that defines a backend data structure as
>> far as I know.
> I think OpenSocial doesn't even define a backend data structure, Shindig does.
> And the same goes for W3C Widgets, while Wookie does have a back-end model.
> The real difference IMO is that Shindig provides an abstract model/SPI while Wookie does not. Yet...
>
> What I've suggested before is the option to modularize Wookie a bit further and see if we can come up with a separate backend model/SPI for Wookie as well.
> Of course that is a discussion for the Wookie project itself, but IMO it is something which would benefit both Wookie and help with a much better integration and support within Rave.
I think its a good idea - Wookie could run in almost pure processing mode with very little persistence beyond the (largely static) widget metadata with the Preference and SharedContext handling delegated using SPIs.
We'd still need a default implementation for standalone Wookie deployment, but even then some pluggability would be a good thing - for example, for better performance I sometimes want to set up the Wave API feature using a Node.js/WebSockets/Redis backend rather than the default JPA/DWR implementation.
The relevant interfaces are IWidgetAPI and IWaveAPI; I guess we would need to provide a means of injecting implementations of these.
Re: Modularization
Posted by Scott Wilson <sc...@gmail.com>.
On 28 May 2012, at 21:55, Chris Geer wrote:
> On Monday, May 28, 2012, Ate Douma wrote:
>
>> On 05/25/2012 10:54 PM, Chris Geer wrote:
>>
>>> To prod along the conversation about modularization and architecture I
>>> wanted to pick one thing and try and talk through it before moving onto
>>> bigger things. Right now Rave has a core data model defined in
>>> org.apache.rave.portal.model which are all concrete JPA classes. To
>>> support
>>> pluggable persistence layers we will need to migrate the definitions to
>>> interfaces and move the JPA implementations to a JPA module. Assuming that
>>> is an agreed upon task I have a couple questions:
>>>
>>> 1) Has any of this been done as part of the JCR activity? Is that still in
>>> progress?
>>>
>> Yes, that still is in progress, or maybe better said in progress getting
>> started :)
>> Unico made a first start with initial JCR bootstrap and initialization
>> features, but he's been on holiday the last 3 weeks (back by tomorrow).
>> Ard joined the effort last week by picking up work on the Jackrabbit JCR
>> OCM module (so within the Jackrabbit project) to get it ready to be used
>> for Rave.
>> The timing of separating out the JPA persistence layer now is perfect in
>> that respect. I expect that in a few weeks time we could start on a partial
>> JCR based back-end for Rave Portal.
>> And Marijan and myself hope to get started with the 'real stuff'
>> concerning content services as well as a HMVC model and layer for the
>> portal site and page management sometime in June.
>> At Hippo we had some business distractions in April with as result that
>> the initial planning and availability for our Rave contributions no longer
>> was valid. We're scheduling this in again ASAP, but it'll take a bit more
>> time now.
>>
>> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>>> OpenSocial is the only one so far that defines a backend data structure as
>>> far as I know.
>>>
>> I think OpenSocial doesn't even define a backend data structure, Shindig
>> does.
>> And the same goes for W3C Widgets, while Wookie does have a back-end model.
>> The real difference IMO is that Shindig provides an abstract model/SPI
>> while Wookie does not. Yet...
>
>
> I'm definitely not a W3C gadget expert but the only "data backed" I see in
> the specs is for storage of preferences [1]. This differs from OpenSocial
> since they define the Core/Social API and Data specs which define things
> like Person, Activity, Group... [2]. I didn't see a similar construct in
> W3C.
Thats correct, Preferences is the only required feature with some kind of data backend.
Wookie also provides an implementation of the Wave Gadget API spec as a Wookie feature, including backend.
> I agree they each have a unique rendering backed but I was referring to
> more the user/social aspects.
>
> [1] http://www.w3.org/2008/webapps/wiki/WidgetSpecs
> [2] http://docs.opensocial.org/display/OSD/Specs
>
>>
>> What I've suggested before is the option to modularize Wookie a bit
>> further and see if we can come up with a separate backend model/SPI for
>> Wookie as well.
>> Of course that is a discussion for the Wookie project itself, but IMO it
>> is something which would benefit both Wookie and help with a much better
>> integration and support within Rave.
>>
>> Regardless however if we can get/add a Wookie model/SPI, I think there is
>> a difference between the data model(s) needed for Widget Containers
>> (Shindig/Wookie/...) and the data model needed for the Rave Portal.
>> To me a OS Person != Rave User
>> And even much more explicit: a OS Group != Rave Group
>
>
> At some point there needs to be a link between a Rave user and an OS person
> representation (at least when runnin OS backend). That relationship could
> be modeled several ways but it simplifies things if a Rave user is a
> superset of OS Person and even implemented the Shindig Person interface to
> avoid translating between objects. At the very least, to support the social
> APIs in OS we need to be able to process/persist OS data.
>
> I fully understand that if you are running a Wookie front end and don't
> need social data you won't need a full blown Person object. The big
> question in my mind though is how is that actually implemented. In Rave, is
> the OS data model (Person, Activity..) truly optional such that you can
> choose uninstall that module and not have that data in your DB? Or is the
> OS data model part of Rave but it just might not be fully used in some
> implementations?
>
> Using Person as the example, is there a Rave Person table that has all the
> fields to fully represent an OS Person and unused fields are just left
> blank/null or is there a Rave Person table that is bare minimum and then a
> OS Person table that links back to the Rave Person table (and maybe a
> Wookie Person table...)?
>
> Maybe our short term task while talking modularization is to draw out the
> Rave data model and how it supports OS data or what additional objects are
> required beyond the core Rave model to fully support OS data.
>
> Maybe a starter question so that I'm on the same page as everyone. Does
> Rave intend to be compliant with the full OpenSocial specification or just
> the OpenSocial gadget spec?
>
>>
>> With that in mind, does it make sense to consider using the
>>> Shindig data interfaces instead of rolling our own and having to translate
>>> between org.apache.rave.portal.model.**Person and
>>> org.apache.shindig.social.**opensocial.model.Person? Do we anticipate
>>> non-OpenSocial data models that compete with the OpenSocial one?
>>>
>>
>> If Wookie could get an backend model/SPI, it might be very beneficial to
>> consider (re)using part of the Shindig model where applicable, of course
>> not so much in API but in model definition and entity naming/concepts.
>> Other than that, I think it doesn't or shouldn't really matter for as much
>> as it only concerns each separate Widget Container model.
>>
>> With respect to the Rave Portal model I don't see how we can or even need
>> to consider competing data models.
>>
>> Ate
>>
>>
>>> Chris
>>>
>>>
>>
RE: Modularization
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Chris Geer [mailto:chris@cxtsoftware.com]
>Sent: Monday, May 28, 2012 4:55 PM
>To: dev@rave.apache.org
>Subject: Re: Modularization
>
>On Monday, May 28, 2012, Ate Douma wrote:
>
>> On 05/25/2012 10:54 PM, Chris Geer wrote:
>>
>>> To prod along the conversation about modularization and architecture I
>>> wanted to pick one thing and try and talk through it before moving onto
>>> bigger things. Right now Rave has a core data model defined in
>>> org.apache.rave.portal.model which are all concrete JPA classes. To
>>> support
>>> pluggable persistence layers we will need to migrate the definitions to
>>> interfaces and move the JPA implementations to a JPA module. Assuming
>that
>>> is an agreed upon task I have a couple questions:
>>>
>>> 1) Has any of this been done as part of the JCR activity? Is that still in
>>> progress?
>>>
>> Yes, that still is in progress, or maybe better said in progress getting
>> started :)
>> Unico made a first start with initial JCR bootstrap and initialization
>> features, but he's been on holiday the last 3 weeks (back by tomorrow).
>> Ard joined the effort last week by picking up work on the Jackrabbit JCR
>> OCM module (so within the Jackrabbit project) to get it ready to be used
>> for Rave.
>> The timing of separating out the JPA persistence layer now is perfect in
>> that respect. I expect that in a few weeks time we could start on a partial
>> JCR based back-end for Rave Portal.
>> And Marijan and myself hope to get started with the 'real stuff'
>> concerning content services as well as a HMVC model and layer for the
>> portal site and page management sometime in June.
>> At Hippo we had some business distractions in April with as result that
>> the initial planning and availability for our Rave contributions no longer
>> was valid. We're scheduling this in again ASAP, but it'll take a bit more
>> time now.
>>
>> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>>> OpenSocial is the only one so far that defines a backend data structure as
>>> far as I know.
>>>
>> I think OpenSocial doesn't even define a backend data structure, Shindig
>> does.
>> And the same goes for W3C Widgets, while Wookie does have a back-end
>model.
>> The real difference IMO is that Shindig provides an abstract model/SPI
>> while Wookie does not. Yet...
>
>
>I'm definitely not a W3C gadget expert but the only "data backed" I see in
>the specs is for storage of preferences [1]. This differs from OpenSocial
>since they define the Core/Social API and Data specs which define things
>like Person, Activity, Group... [2]. I didn't see a similar construct in
>W3C.
>
>I agree they each have a unique rendering backed but I was referring to
>more the user/social aspects.
>
>[1] http://www.w3.org/2008/webapps/wiki/WidgetSpecs
>[2] http://docs.opensocial.org/display/OSD/Specs
>
>>
>> What I've suggested before is the option to modularize Wookie a bit
>> further and see if we can come up with a separate backend model/SPI for
>> Wookie as well.
>> Of course that is a discussion for the Wookie project itself, but IMO it
>> is something which would benefit both Wookie and help with a much better
>> integration and support within Rave.
>>
>> Regardless however if we can get/add a Wookie model/SPI, I think there is
>> a difference between the data model(s) needed for Widget Containers
>> (Shindig/Wookie/...) and the data model needed for the Rave Portal.
>> To me a OS Person != Rave User
>> And even much more explicit: a OS Group != Rave Group
>
>
>At some point there needs to be a link between a Rave user and an OS person
>representation (at least when runnin OS backend). That relationship could
>be modeled several ways but it simplifies things if a Rave user is a
>superset of OS Person and even implemented the Shindig Person interface to
>avoid translating between objects. At the very least, to support the social
>APIs in OS we need to be able to process/persist OS data.
IMO this is the responsibility of the Shindig SPI implementations.
>
>I fully understand that if you are running a Wookie front end and don't
>need social data you won't need a full blown Person object. The big
>question in my mind though is how is that actually implemented. In Rave, is
>the OS data model (Person, Activity..) truly optional such that you can
>choose uninstall that module and not have that data in your DB? Or is the
>OS data model part of Rave but it just might not be fully used in some
>implementations?
>
>Using Person as the example, is there a Rave Person table that has all the
>fields to fully represent an OS Person and unused fields are just left
>blank/null or is there a Rave Person table that is bare minimum and then a
>OS Person table that links back to the Rave Person table (and maybe a
>Wookie Person table...)?
The current implementation is admittedly suboptimal. There are a few Rave person tables, one of which is the person properties table. Data in this table is used to populate the OS person object using the implicit contracts found in the FieldRestrictingPerson class in Rave Shindig.
This was a first attempt at supporting arbitrary OS fields without changing the Model objects. It doesn't help that it was never fully completed. Now that we are moving to interfaces, this will help some; but, what we really need to do is define a solid field definition strategy that is propagated to the various integrated components like Rave & Wookie. There is a placeholder for this on the architecture wiki.
>
>Maybe our short term task while talking modularization is to draw out the
>Rave data model and how it supports OS data or what additional objects are
>required beyond the core Rave model to fully support OS data.
>
>Maybe a starter question so that I'm on the same page as everyone. Does
>Rave intend to be compliant with the full OpenSocial specification or just
>the OpenSocial gadget spec?
Full spec, though Shindig will offer a lot of the REST endpoint compliance (at least initially).
>
>>
>> With that in mind, does it make sense to consider using the
>>> Shindig data interfaces instead of rolling our own and having to translate
>>> between org.apache.rave.portal.model.**Person and
>>> org.apache.shindig.social.**opensocial.model.Person? Do we anticipate
>>> non-OpenSocial data models that compete with the OpenSocial one?
>>>
>>
>> If Wookie could get an backend model/SPI, it might be very beneficial to
>> consider (re)using part of the Shindig model where applicable, of course
>> not so much in API but in model definition and entity naming/concepts.
>> Other than that, I think it doesn't or shouldn't really matter for as much
>> as it only concerns each separate Widget Container model.
>>
>> With respect to the Rave Portal model I don't see how we can or even need
>> to consider competing data models.
>>
>> Ate
>>
>>
>>> Chris
>>>
>>>
>>
Re: Modularization
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Monday, May 28, 2012, Ate Douma wrote:
> On 05/25/2012 10:54 PM, Chris Geer wrote:
>
>> To prod along the conversation about modularization and architecture I
>> wanted to pick one thing and try and talk through it before moving onto
>> bigger things. Right now Rave has a core data model defined in
>> org.apache.rave.portal.model which are all concrete JPA classes. To
>> support
>> pluggable persistence layers we will need to migrate the definitions to
>> interfaces and move the JPA implementations to a JPA module. Assuming that
>> is an agreed upon task I have a couple questions:
>>
>> 1) Has any of this been done as part of the JCR activity? Is that still in
>> progress?
>>
> Yes, that still is in progress, or maybe better said in progress getting
> started :)
> Unico made a first start with initial JCR bootstrap and initialization
> features, but he's been on holiday the last 3 weeks (back by tomorrow).
> Ard joined the effort last week by picking up work on the Jackrabbit JCR
> OCM module (so within the Jackrabbit project) to get it ready to be used
> for Rave.
> The timing of separating out the JPA persistence layer now is perfect in
> that respect. I expect that in a few weeks time we could start on a partial
> JCR based back-end for Rave Portal.
> And Marijan and myself hope to get started with the 'real stuff'
> concerning content services as well as a HMVC model and layer for the
> portal site and page management sometime in June.
> At Hippo we had some business distractions in April with as result that
> the initial planning and availability for our Rave contributions no longer
> was valid. We're scheduling this in again ASAP, but it'll take a bit more
> time now.
>
> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>> OpenSocial is the only one so far that defines a backend data structure as
>> far as I know.
>>
> I think OpenSocial doesn't even define a backend data structure, Shindig
> does.
> And the same goes for W3C Widgets, while Wookie does have a back-end model.
> The real difference IMO is that Shindig provides an abstract model/SPI
> while Wookie does not. Yet...
I'm definitely not a W3C gadget expert but the only "data backed" I see in
the specs is for storage of preferences [1]. This differs from OpenSocial
since they define the Core/Social API and Data specs which define things
like Person, Activity, Group... [2]. I didn't see a similar construct in
W3C.
I agree they each have a unique rendering backed but I was referring to
more the user/social aspects.
[1] http://www.w3.org/2008/webapps/wiki/WidgetSpecs
[2] http://docs.opensocial.org/display/OSD/Specs
>
> What I've suggested before is the option to modularize Wookie a bit
> further and see if we can come up with a separate backend model/SPI for
> Wookie as well.
> Of course that is a discussion for the Wookie project itself, but IMO it
> is something which would benefit both Wookie and help with a much better
> integration and support within Rave.
>
> Regardless however if we can get/add a Wookie model/SPI, I think there is
> a difference between the data model(s) needed for Widget Containers
> (Shindig/Wookie/...) and the data model needed for the Rave Portal.
> To me a OS Person != Rave User
> And even much more explicit: a OS Group != Rave Group
At some point there needs to be a link between a Rave user and an OS person
representation (at least when runnin OS backend). That relationship could
be modeled several ways but it simplifies things if a Rave user is a
superset of OS Person and even implemented the Shindig Person interface to
avoid translating between objects. At the very least, to support the social
APIs in OS we need to be able to process/persist OS data.
I fully understand that if you are running a Wookie front end and don't
need social data you won't need a full blown Person object. The big
question in my mind though is how is that actually implemented. In Rave, is
the OS data model (Person, Activity..) truly optional such that you can
choose uninstall that module and not have that data in your DB? Or is the
OS data model part of Rave but it just might not be fully used in some
implementations?
Using Person as the example, is there a Rave Person table that has all the
fields to fully represent an OS Person and unused fields are just left
blank/null or is there a Rave Person table that is bare minimum and then a
OS Person table that links back to the Rave Person table (and maybe a
Wookie Person table...)?
Maybe our short term task while talking modularization is to draw out the
Rave data model and how it supports OS data or what additional objects are
required beyond the core Rave model to fully support OS data.
Maybe a starter question so that I'm on the same page as everyone. Does
Rave intend to be compliant with the full OpenSocial specification or just
the OpenSocial gadget spec?
>
> With that in mind, does it make sense to consider using the
>> Shindig data interfaces instead of rolling our own and having to translate
>> between org.apache.rave.portal.model.**Person and
>> org.apache.shindig.social.**opensocial.model.Person? Do we anticipate
>> non-OpenSocial data models that compete with the OpenSocial one?
>>
>
> If Wookie could get an backend model/SPI, it might be very beneficial to
> consider (re)using part of the Shindig model where applicable, of course
> not so much in API but in model definition and entity naming/concepts.
> Other than that, I think it doesn't or shouldn't really matter for as much
> as it only concerns each separate Widget Container model.
>
> With respect to the Rave Portal model I don't see how we can or even need
> to consider competing data models.
>
> Ate
>
>
>> Chris
>>
>>
>
Re: Modularization
Posted by Ate Douma <at...@douma.nu>.
On 05/25/2012 10:54 PM, Chris Geer wrote:
> To prod along the conversation about modularization and architecture I
> wanted to pick one thing and try and talk through it before moving onto
> bigger things. Right now Rave has a core data model defined in
> org.apache.rave.portal.model which are all concrete JPA classes. To support
> pluggable persistence layers we will need to migrate the definitions to
> interfaces and move the JPA implementations to a JPA module. Assuming that
> is an agreed upon task I have a couple questions:
>
> 1) Has any of this been done as part of the JCR activity? Is that still in
> progress?
Yes, that still is in progress, or maybe better said in progress getting started :)
Unico made a first start with initial JCR bootstrap and initialization features,
but he's been on holiday the last 3 weeks (back by tomorrow).
Ard joined the effort last week by picking up work on the Jackrabbit JCR OCM
module (so within the Jackrabbit project) to get it ready to be used for Rave.
The timing of separating out the JPA persistence layer now is perfect in that
respect. I expect that in a few weeks time we could start on a partial JCR based
back-end for Rave Portal.
And Marijan and myself hope to get started with the 'real stuff' concerning
content services as well as a HMVC model and layer for the portal site and page
management sometime in June.
At Hippo we had some business distractions in April with as result that the
initial planning and availability for our Rave contributions no longer was
valid. We're scheduling this in again ASAP, but it'll take a bit more time now.
> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
> OpenSocial is the only one so far that defines a backend data structure as
> far as I know.
I think OpenSocial doesn't even define a backend data structure, Shindig does.
And the same goes for W3C Widgets, while Wookie does have a back-end model.
The real difference IMO is that Shindig provides an abstract model/SPI while
Wookie does not. Yet...
What I've suggested before is the option to modularize Wookie a bit further and
see if we can come up with a separate backend model/SPI for Wookie as well.
Of course that is a discussion for the Wookie project itself, but IMO it is
something which would benefit both Wookie and help with a much better
integration and support within Rave.
Regardless however if we can get/add a Wookie model/SPI, I think there is a
difference between the data model(s) needed for Widget Containers
(Shindig/Wookie/...) and the data model needed for the Rave Portal.
To me a OS Person != Rave User
And even much more explicit: a OS Group != Rave Group
> With that in mind, does it make sense to consider using the
> Shindig data interfaces instead of rolling our own and having to translate
> between org.apache.rave.portal.model.Person and
> org.apache.shindig.social.opensocial.model.Person? Do we anticipate
> non-OpenSocial data models that compete with the OpenSocial one?
If Wookie could get an backend model/SPI, it might be very beneficial to
consider (re)using part of the Shindig model where applicable, of course not so
much in API but in model definition and entity naming/concepts.
Other than that, I think it doesn't or shouldn't really matter for as much as it
only concerns each separate Widget Container model.
With respect to the Rave Portal model I don't see how we can or even need to
consider competing data models.
Ate
>
> Chris
>
Re: Modularization
Posted by Scott Wilson <sc...@gmail.com>.
On 28 May 2012, at 21:59, Chris Geer wrote:
> On Mon, May 28, 2012 at 12:45 PM, Ate Douma <at...@douma.nu> wrote:
>
>> On 05/26/2012 06:26 AM, Chris Geer wrote:
>>
>>> On Fri, May 25, 2012 at 8:00 PM, Franklin, Matthew B.
>>> <mf...@mitre.org>wrote:
>>>
>>> On 5/25/12 4:54 PM, "Chris Geer"<ch...@cxtsoftware.com> wrote:
>>>>
>>>> To prod along the conversation about modularization and architecture I
>>>>> wanted to pick one thing and try and talk through it before moving onto
>>>>> bigger things. Right now Rave has a core data model defined in
>>>>> org.apache.rave.portal.model which are all concrete JPA classes. To
>>>>> support
>>>>> pluggable persistence layers we will need to migrate the definitions to
>>>>> interfaces and move the JPA implementations to a JPA module. Assuming
>>>>> that
>>>>> is an agreed upon task I have a couple questions:
>>>>>
>>>>
>>>> +1. Took the words out of my mouth :). Initially a few of us pushed
>>>> pretty hard for the pojo programming model as a shorter entry point, but
>>>> in retrospect, we should have just gone with interfaces as others
>>>> suggested. As part of the roadmap discussion, I was going to propose
>>>> this
>>>> very thing on the wiki. I was going to propose we do this in a branch,
>>>> like we did with Bootstrap.
>>>>
>>>>
>>> I agree, starting a branch to work on this is the right approach when we
>>> start.
>>>
>>>
>>>>
>>>>
>>>>> 1) Has any of this been done as part of the JCR activity? Is that still
>>>>> in
>>>>> progress?
>>>>>
>>>>
>>>> Ate? Unico?
>>>>
>>>> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>>>>> OpenSocial is the only one so far that defines a backend data structure
>>>>> as
>>>>> far as I know. With that in mind, does it make sense to consider using
>>>>> the
>>>>> Shindig data interfaces instead of rolling our own and having to
>>>>> translate
>>>>> between org.apache.rave.portal.model.**Person and
>>>>> org.apache.shindig.social.**opensocial.model.Person? Do we anticipate
>>>>> non-OpenSocial data models that compete with the OpenSocial one?
>>>>>
>>>>
>>>> We attempted to keep OS or Wookie dependencies out of the core so that we
>>>> can support the case where people don't actually run Rave with OpenSocial
>>>> support (IE Wookie only) or with a custom renderer and no Wookie or Rave.
>>>>
>>>>
>>> Conceptually, I agree with this but I wonder how different Rave Core can
>>> really be than OpenSocial and still meet compliance. At some point it
>>> becomes really painful. I guess my point of view (maybe selfishly) is that
>>> Rave shouldn't try to be everything to everybody (if someone needs a
>>> highly
>>> custom back end and doesn't want to use Wookie or OpenSocial are they
>>> really using Rave?) but should focus on being a kick butt OpenSocial
>>> server
>>> that also supports W3C gadgets (Or run only W3C gadgets with an OpenSocial
>>> backend since Wookie can work with the APIs).
>>>
>>
>> To be honest, right now I don't see much desire to support other Widget
>> like containers other than OpenSocial and W3C Widgets. However I do see
>> those two as critical to be supported both.
>>
>> I also think that you can't 'just' run W3C widgets with only an OpenSocial
>> backend. Wookie might support running OpenSocial gadgets (to some extend)
>> but also needs its own server/backend model as well. Which you will always
>> need for 'native' W3C Widgets. And running OpenSocial Gadgets via Wookie
>> through Rave doesn't make sense to me. It might be useful for a Wookie-only
>> setup, but not if you already have full OpenSocial support within Rave.
>>
>
> When I was using the term "backend" here I was talking about the
> Social/Data part of OS, not the gadget rendering part. I thought I read
> somewhere that Wookie had support for accessing OS social/data APIs from
> it's W3C widgets.
Yes, its not really up to date, but we can in principle inject OSAPI features into W3C Widgets, and we have some proof-of-concept code for that in the Wookie scratchpad area. However there is no back-end for this, we'd just delegate it to the Rave container.
>
>>
>> Ate
>>
>>
>>>
>>>>
>>>>> Chris
>>>>>
>>>>
>>>>
>>>>
>>>
>>
Re: Modularization
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Mon, May 28, 2012 at 12:45 PM, Ate Douma <at...@douma.nu> wrote:
> On 05/26/2012 06:26 AM, Chris Geer wrote:
>
>> On Fri, May 25, 2012 at 8:00 PM, Franklin, Matthew B.
>> <mf...@mitre.org>wrote:
>>
>> On 5/25/12 4:54 PM, "Chris Geer"<ch...@cxtsoftware.com> wrote:
>>>
>>> To prod along the conversation about modularization and architecture I
>>>> wanted to pick one thing and try and talk through it before moving onto
>>>> bigger things. Right now Rave has a core data model defined in
>>>> org.apache.rave.portal.model which are all concrete JPA classes. To
>>>> support
>>>> pluggable persistence layers we will need to migrate the definitions to
>>>> interfaces and move the JPA implementations to a JPA module. Assuming
>>>> that
>>>> is an agreed upon task I have a couple questions:
>>>>
>>>
>>> +1. Took the words out of my mouth :). Initially a few of us pushed
>>> pretty hard for the pojo programming model as a shorter entry point, but
>>> in retrospect, we should have just gone with interfaces as others
>>> suggested. As part of the roadmap discussion, I was going to propose
>>> this
>>> very thing on the wiki. I was going to propose we do this in a branch,
>>> like we did with Bootstrap.
>>>
>>>
>> I agree, starting a branch to work on this is the right approach when we
>> start.
>>
>>
>>>
>>>
>>>> 1) Has any of this been done as part of the JCR activity? Is that still
>>>> in
>>>> progress?
>>>>
>>>
>>> Ate? Unico?
>>>
>>> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>>>> OpenSocial is the only one so far that defines a backend data structure
>>>> as
>>>> far as I know. With that in mind, does it make sense to consider using
>>>> the
>>>> Shindig data interfaces instead of rolling our own and having to
>>>> translate
>>>> between org.apache.rave.portal.model.**Person and
>>>> org.apache.shindig.social.**opensocial.model.Person? Do we anticipate
>>>> non-OpenSocial data models that compete with the OpenSocial one?
>>>>
>>>
>>> We attempted to keep OS or Wookie dependencies out of the core so that we
>>> can support the case where people don't actually run Rave with OpenSocial
>>> support (IE Wookie only) or with a custom renderer and no Wookie or Rave.
>>>
>>>
>> Conceptually, I agree with this but I wonder how different Rave Core can
>> really be than OpenSocial and still meet compliance. At some point it
>> becomes really painful. I guess my point of view (maybe selfishly) is that
>> Rave shouldn't try to be everything to everybody (if someone needs a
>> highly
>> custom back end and doesn't want to use Wookie or OpenSocial are they
>> really using Rave?) but should focus on being a kick butt OpenSocial
>> server
>> that also supports W3C gadgets (Or run only W3C gadgets with an OpenSocial
>> backend since Wookie can work with the APIs).
>>
>
> To be honest, right now I don't see much desire to support other Widget
> like containers other than OpenSocial and W3C Widgets. However I do see
> those two as critical to be supported both.
>
> I also think that you can't 'just' run W3C widgets with only an OpenSocial
> backend. Wookie might support running OpenSocial gadgets (to some extend)
> but also needs its own server/backend model as well. Which you will always
> need for 'native' W3C Widgets. And running OpenSocial Gadgets via Wookie
> through Rave doesn't make sense to me. It might be useful for a Wookie-only
> setup, but not if you already have full OpenSocial support within Rave.
>
When I was using the term "backend" here I was talking about the
Social/Data part of OS, not the gadget rendering part. I thought I read
somewhere that Wookie had support for accessing OS social/data APIs from
it's W3C widgets.
>
> Ate
>
>
>>
>>>
>>>> Chris
>>>>
>>>
>>>
>>>
>>
>
Re: Modularization
Posted by Ate Douma <at...@douma.nu>.
On 05/26/2012 06:26 AM, Chris Geer wrote:
> On Fri, May 25, 2012 at 8:00 PM, Franklin, Matthew B.
> <mf...@mitre.org>wrote:
>
>> On 5/25/12 4:54 PM, "Chris Geer"<ch...@cxtsoftware.com> wrote:
>>
>>> To prod along the conversation about modularization and architecture I
>>> wanted to pick one thing and try and talk through it before moving onto
>>> bigger things. Right now Rave has a core data model defined in
>>> org.apache.rave.portal.model which are all concrete JPA classes. To
>>> support
>>> pluggable persistence layers we will need to migrate the definitions to
>>> interfaces and move the JPA implementations to a JPA module. Assuming that
>>> is an agreed upon task I have a couple questions:
>>
>> +1. Took the words out of my mouth :). Initially a few of us pushed
>> pretty hard for the pojo programming model as a shorter entry point, but
>> in retrospect, we should have just gone with interfaces as others
>> suggested. As part of the roadmap discussion, I was going to propose this
>> very thing on the wiki. I was going to propose we do this in a branch,
>> like we did with Bootstrap.
>>
>
> I agree, starting a branch to work on this is the right approach when we
> start.
>
>>
>>
>>>
>>> 1) Has any of this been done as part of the JCR activity? Is that still in
>>> progress?
>>
>> Ate? Unico?
>>
>>> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>>> OpenSocial is the only one so far that defines a backend data structure as
>>> far as I know. With that in mind, does it make sense to consider using the
>>> Shindig data interfaces instead of rolling our own and having to translate
>>> between org.apache.rave.portal.model.Person and
>>> org.apache.shindig.social.opensocial.model.Person? Do we anticipate
>>> non-OpenSocial data models that compete with the OpenSocial one?
>>
>> We attempted to keep OS or Wookie dependencies out of the core so that we
>> can support the case where people don't actually run Rave with OpenSocial
>> support (IE Wookie only) or with a custom renderer and no Wookie or Rave.
>>
>
> Conceptually, I agree with this but I wonder how different Rave Core can
> really be than OpenSocial and still meet compliance. At some point it
> becomes really painful. I guess my point of view (maybe selfishly) is that
> Rave shouldn't try to be everything to everybody (if someone needs a highly
> custom back end and doesn't want to use Wookie or OpenSocial are they
> really using Rave?) but should focus on being a kick butt OpenSocial server
> that also supports W3C gadgets (Or run only W3C gadgets with an OpenSocial
> backend since Wookie can work with the APIs).
To be honest, right now I don't see much desire to support other Widget like
containers other than OpenSocial and W3C Widgets. However I do see those two as
critical to be supported both.
I also think that you can't 'just' run W3C widgets with only an OpenSocial
backend. Wookie might support running OpenSocial gadgets (to some extend) but
also needs its own server/backend model as well. Which you will always need for
'native' W3C Widgets. And running OpenSocial Gadgets via Wookie through Rave
doesn't make sense to me. It might be useful for a Wookie-only setup, but not if
you already have full OpenSocial support within Rave.
Ate
>
>>
>>>
>>> Chris
>>
>>
>
RE: Modularization
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Chris Geer [mailto:chris@cxtsoftware.com]
>Sent: Saturday, May 26, 2012 12:27 AM
>To: dev@rave.apache.org
>Subject: Re: Modularization
>
>On Fri, May 25, 2012 at 8:00 PM, Franklin, Matthew B.
><mf...@mitre.org>wrote:
>
>> On 5/25/12 4:54 PM, "Chris Geer" <ch...@cxtsoftware.com> wrote:
>>
>> >To prod along the conversation about modularization and architecture I
>> >wanted to pick one thing and try and talk through it before moving onto
>> >bigger things. Right now Rave has a core data model defined in
>> >org.apache.rave.portal.model which are all concrete JPA classes. To
>> >support
>> >pluggable persistence layers we will need to migrate the definitions to
>> >interfaces and move the JPA implementations to a JPA module. Assuming
>that
>> >is an agreed upon task I have a couple questions:
>>
>> +1. Took the words out of my mouth :). Initially a few of us pushed
>> pretty hard for the pojo programming model as a shorter entry point, but
>> in retrospect, we should have just gone with interfaces as others
>> suggested. As part of the roadmap discussion, I was going to propose this
>> very thing on the wiki. I was going to propose we do this in a branch,
>> like we did with Bootstrap.
>>
>
>I agree, starting a branch to work on this is the right approach when we
>start.
>
>>
>>
>> >
>> >1) Has any of this been done as part of the JCR activity? Is that still in
>> >progress?
>>
>> Ate? Unico?
>>
>> >2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>> >OpenSocial is the only one so far that defines a backend data structure as
>> >far as I know. With that in mind, does it make sense to consider using the
>> >Shindig data interfaces instead of rolling our own and having to translate
>> >between org.apache.rave.portal.model.Person and
>> >org.apache.shindig.social.opensocial.model.Person? Do we anticipate
>> >non-OpenSocial data models that compete with the OpenSocial one?
>>
>> We attempted to keep OS or Wookie dependencies out of the core so that
>we
>> can support the case where people don't actually run Rave with OpenSocial
>> support (IE Wookie only) or with a custom renderer and no Wookie or Rave.
>>
>
>Conceptually, I agree with this but I wonder how different Rave Core can
>really be than OpenSocial and still meet compliance. At some point it
>becomes really painful. I guess my point of view (maybe selfishly) is that
>Rave shouldn't try to be everything to everybody (if someone needs a highly
>custom back end and doesn't want to use Wookie or OpenSocial are they
>really using Rave?) but should focus on being a kick butt OpenSocial server
>that also supports W3C gadgets (Or run only W3C gadgets with an OpenSocial
>backend since Wookie can work with the APIs).
Most of the of OpenSocial that the Rave core would need to be aware of (at least initially) are actually externalized specs: Portable Contacts & ActivityStreams. I agree translation is not fun though... One big thing to think about in this same space is field support. OpenSocial doesn't require much and we would need a simple way to define what fields Rave & Rave-Shindig support.
>
>>
>> >
>> >Chris
>>
>>
Re: Modularization
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Fri, May 25, 2012 at 8:00 PM, Franklin, Matthew B.
<mf...@mitre.org>wrote:
> On 5/25/12 4:54 PM, "Chris Geer" <ch...@cxtsoftware.com> wrote:
>
> >To prod along the conversation about modularization and architecture I
> >wanted to pick one thing and try and talk through it before moving onto
> >bigger things. Right now Rave has a core data model defined in
> >org.apache.rave.portal.model which are all concrete JPA classes. To
> >support
> >pluggable persistence layers we will need to migrate the definitions to
> >interfaces and move the JPA implementations to a JPA module. Assuming that
> >is an agreed upon task I have a couple questions:
>
> +1. Took the words out of my mouth :). Initially a few of us pushed
> pretty hard for the pojo programming model as a shorter entry point, but
> in retrospect, we should have just gone with interfaces as others
> suggested. As part of the roadmap discussion, I was going to propose this
> very thing on the wiki. I was going to propose we do this in a branch,
> like we did with Bootstrap.
>
I agree, starting a branch to work on this is the right approach when we
start.
>
>
> >
> >1) Has any of this been done as part of the JCR activity? Is that still in
> >progress?
>
> Ate? Unico?
>
> >2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
> >OpenSocial is the only one so far that defines a backend data structure as
> >far as I know. With that in mind, does it make sense to consider using the
> >Shindig data interfaces instead of rolling our own and having to translate
> >between org.apache.rave.portal.model.Person and
> >org.apache.shindig.social.opensocial.model.Person? Do we anticipate
> >non-OpenSocial data models that compete with the OpenSocial one?
>
> We attempted to keep OS or Wookie dependencies out of the core so that we
> can support the case where people don't actually run Rave with OpenSocial
> support (IE Wookie only) or with a custom renderer and no Wookie or Rave.
>
Conceptually, I agree with this but I wonder how different Rave Core can
really be than OpenSocial and still meet compliance. At some point it
becomes really painful. I guess my point of view (maybe selfishly) is that
Rave shouldn't try to be everything to everybody (if someone needs a highly
custom back end and doesn't want to use Wookie or OpenSocial are they
really using Rave?) but should focus on being a kick butt OpenSocial server
that also supports W3C gadgets (Or run only W3C gadgets with an OpenSocial
backend since Wookie can work with the APIs).
>
> >
> >Chris
>
>
Re: Modularization
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 5/25/12 4:54 PM, "Chris Geer" <ch...@cxtsoftware.com> wrote:
>To prod along the conversation about modularization and architecture I
>wanted to pick one thing and try and talk through it before moving onto
>bigger things. Right now Rave has a core data model defined in
>org.apache.rave.portal.model which are all concrete JPA classes. To
>support
>pluggable persistence layers we will need to migrate the definitions to
>interfaces and move the JPA implementations to a JPA module. Assuming that
>is an agreed upon task I have a couple questions:
+1. Took the words out of my mouth :). Initially a few of us pushed
pretty hard for the pojo programming model as a shorter entry point, but
in retrospect, we should have just gone with interfaces as others
suggested. As part of the roadmap discussion, I was going to propose this
very thing on the wiki. I was going to propose we do this in a branch,
like we did with Bootstrap.
>
>1) Has any of this been done as part of the JCR activity? Is that still in
>progress?
Ate? Unico?
>2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>OpenSocial is the only one so far that defines a backend data structure as
>far as I know. With that in mind, does it make sense to consider using the
>Shindig data interfaces instead of rolling our own and having to translate
>between org.apache.rave.portal.model.Person and
>org.apache.shindig.social.opensocial.model.Person? Do we anticipate
>non-OpenSocial data models that compete with the OpenSocial one?
We attempted to keep OS or Wookie dependencies out of the core so that we
can support the case where people don't actually run Rave with OpenSocial
support (IE Wookie only) or with a custom renderer and no Wookie or Rave.
>
>Chris