You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Zhenhua (Gerald) Guo" <je...@gmail.com> on 2011/05/11 05:42:53 UTC
OpenSocial Person related SPI implementation
I just created a JIRA sub-task for OpenSocial Person related SPI implementation.
The Person object is specified in OpenSocial spec 2.0
http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Person.
In RAVE, we have already had User class. However, our existing User
class serves different purposes than OpenSocial Person object.
I am considering implementing Person related SPIs, at least GetPerson
SPI, if nobody else is implementing it. In the first step, I will use
our existing User class and expose basic user information (e.g.
username) to Shindig. Then I will extend User class (or write a
completely new class) to add more fields required by OpenSocial Person
data structure/model.
Any comments on this? Is the proposed implementation strategy appropriate?
Thanks,
Gerald
Re: OpenSocial Person related SPI implementation
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
Sounds good. Thanks Gerald.
-Matt
On 5/26/11 4:54 PM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>I added it originally. We don't have any use case and UI support for
>social features (e.g. friends, activity streams). Currently, most of
>our work is related to gadget rendering and integration with Wookie.
>So I removed it from 0.1 release schedule.
>
>Gerald
>
>On Tue, May 24, 2011 at 2:19 PM, Franklin, Matthew B.
><mf...@mitre.org> wrote:
>> Where do we stand on the SPI implementation? Are they good to go for
>>the
>> first release? I haven't seen any of the SPI issues get updated in JIRA
>> and from looking around the archives, I think there were still some open
>> questions.
>>
>> Since someone added the issues to the 0.1 release schedule, I think we
>> either need to make sure they get done, or pull them off and put them in
>> the next release.
>>
>> -Matt
>>
>> On 5/18/11 12:00 PM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>>
>>>Probably some experts from both worlds can clarify to what extent
>>>OpenSocial data models and W3C widget data models differ. It may
>>>bring difficulties if data models from different standards cannot be
>>>easily mapped. However, I would image they are similar more or less.
>>>Anyway, I think it's a good idea to have a separate independent
>>>"social data store" module, which exposes REST services that can be
>>>called by whatever clients (e.g. OpenSocial, W3C Widget). Then we
>>>have unified data models and data access module.
>>>
>>>Gerald
>>>
>>>
>>>On Wed, May 18, 2011 at 9:38 AM, Franklin, Matthew B.
>>><mf...@mitre.org> wrote:
>>>> On 5/18/11 12:06 AM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>>>>
>>>>>Just committed code for initial SPI implementation (JPA is used).
>>>>>Based on response in previous emails, I put the code into
>>>>>rave-shindig. Current user table is not used at all because it's more
>>>>>a user management oriented object. Instead a table "person" (with some
>>>>>other tables) is created for storing information of OpenSocial
>>>>>persons.
>>>>>
>>>>>@Matt
>>>>>It's a good idea to create unified REST services accessed by both
>>>>>Shindig and portal. However, if Opensocial REST services are enough
>>>>>(don't need other services), the unified REST service layer may not be
>>>>>necessary. If we need more services than those provided by OpenSocial
>>>>>spec, we can either extend OpenSocial, or as you said, build another
>>>>>layer encapsulating OpenSocial services and other services.
>>>>
>>>> I think we need to make a decision as to whether Rave is going to be
>>>>an
>>>> OpenSocial container that can render W3C widgets or is a widget mashup
>>>> engine with support for OpenSocial, W3C and other widget frameworks.
>>>>This
>>>> decision will help us decide to what degree we depend on Shindig.
>>>>
>>>> My current thinking is that Rave manages the core data (people,
>>>>widgets,
>>>> pages, etc) and it gets re-exposed via the rendering engines. This
>>>>means
>>>> you *could* deploy rave with no OpenSocial support and only W3C or
>>>> vice-versa.
>>>>
>>>>>Above considerations are based on my knowledge about gadgets and
>>>>>OpenSocial. To support other types of widgets (e.g. W3C widget),
>>>>>probably more careful investigation is required.
>>>>>
>>>>>
>>>>>@Ate
>>>>>I talked with Marlon about data access component. Besides what you
>>>>>proposed (writing separate database access module), another strategy
>>>>>is that all database accesses, not only OpenSocial data accesses but
>>>>>also RAVE portal data acceses, are delegated to Shindig. For example,
>>>>>when user logs in RAVE portal, a request is sent to portal to get
>>>>>user's layout data. This request is received by portal and data
>>>>>access request is sent to Shindig. In other words, all data is
>>>>>managed by Shindig. To do so, OpenSocial data objects need to be
>>>>>extended to include RAVE portal data. For example, Person object can
>>>>>be extended to include 1) the user's portal layout data 2) the user's
>>>>>gadget preferences 3) more authenticated information, etc. It may or
>>>>>may not work well in reality. Just my (and Marlon's) 0.02 cents.
>>>>>
>>>>>
>>>>>Gerald
>>>>>
>>>>>On Mon, May 16, 2011 at 1:22 PM, Franklin, Matthew B.
>>>>><mf...@mitre.org> wrote:
>>>>>> On 5/13/11 11:33 AM, "Ate Douma" <at...@douma.nu> wrote:
>>>>>>
>>>>>>>Another benefit I forgot to add of creating a separate database
>>>>>>>access
>>>>>>>module
>>>>>>>would be that it allows creating other (portal independent)
>>>>>>>applications
>>>>>>>like an
>>>>>>>admin console for maintenance purposes or reporting solutions which
>>>>>>>don't
>>>>>>>need
>>>>>>>and possibly even are undesired to be integrated directly in the
>>>>>>>portal.
>>>>>>>Of course, for that we could also add an additional REST or RPC
>>>>>>>services
>>>>>>>layer
>>>>>>>within the portal (and we also can do both), but for low-level/admin
>>>>>>>usage a
>>>>>>>direct database access layer probably might be easier and preferred.
>>>>>>
>>>>>> This sounds similar to the approach that Jesse took internally for
>>>>>>OSEC
>>>>>> (unless I am misreading the comments). He created a backend person
>>>>>>REST
>>>>>> service that both Shindig and OSEC connect to.
>>>>>>
>>>>>> Given that Rave is going to be integrating multiple widget
>>>>>>renderers,
>>>>>>it
>>>>>> might make sense to build a central component that manages the data
>>>>>>store
>>>>>> for information (like person) that is common amongst all components,
>>>>>>then
>>>>>> provide an API for access by Shindig, portal and Wookie.
>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: OpenSocial Person related SPI implementation
Posted by "Zhenhua (Gerald) Guo" <je...@gmail.com>.
I added it originally. We don't have any use case and UI support for
social features (e.g. friends, activity streams). Currently, most of
our work is related to gadget rendering and integration with Wookie.
So I removed it from 0.1 release schedule.
Gerald
On Tue, May 24, 2011 at 2:19 PM, Franklin, Matthew B.
<mf...@mitre.org> wrote:
> Where do we stand on the SPI implementation? Are they good to go for the
> first release? I haven't seen any of the SPI issues get updated in JIRA
> and from looking around the archives, I think there were still some open
> questions.
>
> Since someone added the issues to the 0.1 release schedule, I think we
> either need to make sure they get done, or pull them off and put them in
> the next release.
>
> -Matt
>
> On 5/18/11 12:00 PM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>
>>Probably some experts from both worlds can clarify to what extent
>>OpenSocial data models and W3C widget data models differ. It may
>>bring difficulties if data models from different standards cannot be
>>easily mapped. However, I would image they are similar more or less.
>>Anyway, I think it's a good idea to have a separate independent
>>"social data store" module, which exposes REST services that can be
>>called by whatever clients (e.g. OpenSocial, W3C Widget). Then we
>>have unified data models and data access module.
>>
>>Gerald
>>
>>
>>On Wed, May 18, 2011 at 9:38 AM, Franklin, Matthew B.
>><mf...@mitre.org> wrote:
>>> On 5/18/11 12:06 AM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>>>
>>>>Just committed code for initial SPI implementation (JPA is used).
>>>>Based on response in previous emails, I put the code into
>>>>rave-shindig. Current user table is not used at all because it's more
>>>>a user management oriented object. Instead a table "person" (with some
>>>>other tables) is created for storing information of OpenSocial
>>>>persons.
>>>>
>>>>@Matt
>>>>It's a good idea to create unified REST services accessed by both
>>>>Shindig and portal. However, if Opensocial REST services are enough
>>>>(don't need other services), the unified REST service layer may not be
>>>>necessary. If we need more services than those provided by OpenSocial
>>>>spec, we can either extend OpenSocial, or as you said, build another
>>>>layer encapsulating OpenSocial services and other services.
>>>
>>> I think we need to make a decision as to whether Rave is going to be an
>>> OpenSocial container that can render W3C widgets or is a widget mashup
>>> engine with support for OpenSocial, W3C and other widget frameworks.
>>>This
>>> decision will help us decide to what degree we depend on Shindig.
>>>
>>> My current thinking is that Rave manages the core data (people, widgets,
>>> pages, etc) and it gets re-exposed via the rendering engines. This
>>>means
>>> you *could* deploy rave with no OpenSocial support and only W3C or
>>> vice-versa.
>>>
>>>>Above considerations are based on my knowledge about gadgets and
>>>>OpenSocial. To support other types of widgets (e.g. W3C widget),
>>>>probably more careful investigation is required.
>>>>
>>>>
>>>>@Ate
>>>>I talked with Marlon about data access component. Besides what you
>>>>proposed (writing separate database access module), another strategy
>>>>is that all database accesses, not only OpenSocial data accesses but
>>>>also RAVE portal data acceses, are delegated to Shindig. For example,
>>>>when user logs in RAVE portal, a request is sent to portal to get
>>>>user's layout data. This request is received by portal and data
>>>>access request is sent to Shindig. In other words, all data is
>>>>managed by Shindig. To do so, OpenSocial data objects need to be
>>>>extended to include RAVE portal data. For example, Person object can
>>>>be extended to include 1) the user's portal layout data 2) the user's
>>>>gadget preferences 3) more authenticated information, etc. It may or
>>>>may not work well in reality. Just my (and Marlon's) 0.02 cents.
>>>>
>>>>
>>>>Gerald
>>>>
>>>>On Mon, May 16, 2011 at 1:22 PM, Franklin, Matthew B.
>>>><mf...@mitre.org> wrote:
>>>>> On 5/13/11 11:33 AM, "Ate Douma" <at...@douma.nu> wrote:
>>>>>
>>>>>>Another benefit I forgot to add of creating a separate database access
>>>>>>module
>>>>>>would be that it allows creating other (portal independent)
>>>>>>applications
>>>>>>like an
>>>>>>admin console for maintenance purposes or reporting solutions which
>>>>>>don't
>>>>>>need
>>>>>>and possibly even are undesired to be integrated directly in the
>>>>>>portal.
>>>>>>Of course, for that we could also add an additional REST or RPC
>>>>>>services
>>>>>>layer
>>>>>>within the portal (and we also can do both), but for low-level/admin
>>>>>>usage a
>>>>>>direct database access layer probably might be easier and preferred.
>>>>>
>>>>> This sounds similar to the approach that Jesse took internally for
>>>>>OSEC
>>>>> (unless I am misreading the comments). He created a backend person
>>>>>REST
>>>>> service that both Shindig and OSEC connect to.
>>>>>
>>>>> Given that Rave is going to be integrating multiple widget renderers,
>>>>>it
>>>>> might make sense to build a central component that manages the data
>>>>>store
>>>>> for information (like person) that is common amongst all components,
>>>>>then
>>>>> provide an API for access by Shindig, portal and Wookie.
>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: OpenSocial Person related SPI implementation
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
Where do we stand on the SPI implementation? Are they good to go for the
first release? I haven't seen any of the SPI issues get updated in JIRA
and from looking around the archives, I think there were still some open
questions.
Since someone added the issues to the 0.1 release schedule, I think we
either need to make sure they get done, or pull them off and put them in
the next release.
-Matt
On 5/18/11 12:00 PM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>Probably some experts from both worlds can clarify to what extent
>OpenSocial data models and W3C widget data models differ. It may
>bring difficulties if data models from different standards cannot be
>easily mapped. However, I would image they are similar more or less.
>Anyway, I think it's a good idea to have a separate independent
>"social data store" module, which exposes REST services that can be
>called by whatever clients (e.g. OpenSocial, W3C Widget). Then we
>have unified data models and data access module.
>
>Gerald
>
>
>On Wed, May 18, 2011 at 9:38 AM, Franklin, Matthew B.
><mf...@mitre.org> wrote:
>> On 5/18/11 12:06 AM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>>
>>>Just committed code for initial SPI implementation (JPA is used).
>>>Based on response in previous emails, I put the code into
>>>rave-shindig. Current user table is not used at all because it's more
>>>a user management oriented object. Instead a table "person" (with some
>>>other tables) is created for storing information of OpenSocial
>>>persons.
>>>
>>>@Matt
>>>It's a good idea to create unified REST services accessed by both
>>>Shindig and portal. However, if Opensocial REST services are enough
>>>(don't need other services), the unified REST service layer may not be
>>>necessary. If we need more services than those provided by OpenSocial
>>>spec, we can either extend OpenSocial, or as you said, build another
>>>layer encapsulating OpenSocial services and other services.
>>
>> I think we need to make a decision as to whether Rave is going to be an
>> OpenSocial container that can render W3C widgets or is a widget mashup
>> engine with support for OpenSocial, W3C and other widget frameworks.
>>This
>> decision will help us decide to what degree we depend on Shindig.
>>
>> My current thinking is that Rave manages the core data (people, widgets,
>> pages, etc) and it gets re-exposed via the rendering engines. This
>>means
>> you *could* deploy rave with no OpenSocial support and only W3C or
>> vice-versa.
>>
>>>Above considerations are based on my knowledge about gadgets and
>>>OpenSocial. To support other types of widgets (e.g. W3C widget),
>>>probably more careful investigation is required.
>>>
>>>
>>>@Ate
>>>I talked with Marlon about data access component. Besides what you
>>>proposed (writing separate database access module), another strategy
>>>is that all database accesses, not only OpenSocial data accesses but
>>>also RAVE portal data acceses, are delegated to Shindig. For example,
>>>when user logs in RAVE portal, a request is sent to portal to get
>>>user's layout data. This request is received by portal and data
>>>access request is sent to Shindig. In other words, all data is
>>>managed by Shindig. To do so, OpenSocial data objects need to be
>>>extended to include RAVE portal data. For example, Person object can
>>>be extended to include 1) the user's portal layout data 2) the user's
>>>gadget preferences 3) more authenticated information, etc. It may or
>>>may not work well in reality. Just my (and Marlon's) 0.02 cents.
>>>
>>>
>>>Gerald
>>>
>>>On Mon, May 16, 2011 at 1:22 PM, Franklin, Matthew B.
>>><mf...@mitre.org> wrote:
>>>> On 5/13/11 11:33 AM, "Ate Douma" <at...@douma.nu> wrote:
>>>>
>>>>>Another benefit I forgot to add of creating a separate database access
>>>>>module
>>>>>would be that it allows creating other (portal independent)
>>>>>applications
>>>>>like an
>>>>>admin console for maintenance purposes or reporting solutions which
>>>>>don't
>>>>>need
>>>>>and possibly even are undesired to be integrated directly in the
>>>>>portal.
>>>>>Of course, for that we could also add an additional REST or RPC
>>>>>services
>>>>>layer
>>>>>within the portal (and we also can do both), but for low-level/admin
>>>>>usage a
>>>>>direct database access layer probably might be easier and preferred.
>>>>
>>>> This sounds similar to the approach that Jesse took internally for
>>>>OSEC
>>>> (unless I am misreading the comments). He created a backend person
>>>>REST
>>>> service that both Shindig and OSEC connect to.
>>>>
>>>> Given that Rave is going to be integrating multiple widget renderers,
>>>>it
>>>> might make sense to build a central component that manages the data
>>>>store
>>>> for information (like person) that is common amongst all components,
>>>>then
>>>> provide an API for access by Shindig, portal and Wookie.
>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: OpenSocial Person related SPI implementation
Posted by "Zhenhua (Gerald) Guo" <je...@gmail.com>.
Probably some experts from both worlds can clarify to what extent
OpenSocial data models and W3C widget data models differ. It may
bring difficulties if data models from different standards cannot be
easily mapped. However, I would image they are similar more or less.
Anyway, I think it's a good idea to have a separate independent
"social data store" module, which exposes REST services that can be
called by whatever clients (e.g. OpenSocial, W3C Widget). Then we
have unified data models and data access module.
Gerald
On Wed, May 18, 2011 at 9:38 AM, Franklin, Matthew B.
<mf...@mitre.org> wrote:
> On 5/18/11 12:06 AM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>
>>Just committed code for initial SPI implementation (JPA is used).
>>Based on response in previous emails, I put the code into
>>rave-shindig. Current user table is not used at all because it's more
>>a user management oriented object. Instead a table "person" (with some
>>other tables) is created for storing information of OpenSocial
>>persons.
>>
>>@Matt
>>It's a good idea to create unified REST services accessed by both
>>Shindig and portal. However, if Opensocial REST services are enough
>>(don't need other services), the unified REST service layer may not be
>>necessary. If we need more services than those provided by OpenSocial
>>spec, we can either extend OpenSocial, or as you said, build another
>>layer encapsulating OpenSocial services and other services.
>
> I think we need to make a decision as to whether Rave is going to be an
> OpenSocial container that can render W3C widgets or is a widget mashup
> engine with support for OpenSocial, W3C and other widget frameworks. This
> decision will help us decide to what degree we depend on Shindig.
>
> My current thinking is that Rave manages the core data (people, widgets,
> pages, etc) and it gets re-exposed via the rendering engines. This means
> you *could* deploy rave with no OpenSocial support and only W3C or
> vice-versa.
>
>>Above considerations are based on my knowledge about gadgets and
>>OpenSocial. To support other types of widgets (e.g. W3C widget),
>>probably more careful investigation is required.
>>
>>
>>@Ate
>>I talked with Marlon about data access component. Besides what you
>>proposed (writing separate database access module), another strategy
>>is that all database accesses, not only OpenSocial data accesses but
>>also RAVE portal data acceses, are delegated to Shindig. For example,
>>when user logs in RAVE portal, a request is sent to portal to get
>>user's layout data. This request is received by portal and data
>>access request is sent to Shindig. In other words, all data is
>>managed by Shindig. To do so, OpenSocial data objects need to be
>>extended to include RAVE portal data. For example, Person object can
>>be extended to include 1) the user's portal layout data 2) the user's
>>gadget preferences 3) more authenticated information, etc. It may or
>>may not work well in reality. Just my (and Marlon's) 0.02 cents.
>>
>>
>>Gerald
>>
>>On Mon, May 16, 2011 at 1:22 PM, Franklin, Matthew B.
>><mf...@mitre.org> wrote:
>>> On 5/13/11 11:33 AM, "Ate Douma" <at...@douma.nu> wrote:
>>>
>>>>Another benefit I forgot to add of creating a separate database access
>>>>module
>>>>would be that it allows creating other (portal independent) applications
>>>>like an
>>>>admin console for maintenance purposes or reporting solutions which
>>>>don't
>>>>need
>>>>and possibly even are undesired to be integrated directly in the portal.
>>>>Of course, for that we could also add an additional REST or RPC services
>>>>layer
>>>>within the portal (and we also can do both), but for low-level/admin
>>>>usage a
>>>>direct database access layer probably might be easier and preferred.
>>>
>>> This sounds similar to the approach that Jesse took internally for OSEC
>>> (unless I am misreading the comments). He created a backend person REST
>>> service that both Shindig and OSEC connect to.
>>>
>>> Given that Rave is going to be integrating multiple widget renderers, it
>>> might make sense to build a central component that manages the data
>>>store
>>> for information (like person) that is common amongst all components,
>>>then
>>> provide an API for access by Shindig, portal and Wookie.
>>>
>>>>
>>>
>>>
>
>
Re: OpenSocial Person related SPI implementation
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 5/18/11 12:06 AM, "Zhenhua (Gerald) Guo" <je...@gmail.com> wrote:
>Just committed code for initial SPI implementation (JPA is used).
>Based on response in previous emails, I put the code into
>rave-shindig. Current user table is not used at all because it's more
>a user management oriented object. Instead a table "person" (with some
>other tables) is created for storing information of OpenSocial
>persons.
>
>@Matt
>It's a good idea to create unified REST services accessed by both
>Shindig and portal. However, if Opensocial REST services are enough
>(don't need other services), the unified REST service layer may not be
>necessary. If we need more services than those provided by OpenSocial
>spec, we can either extend OpenSocial, or as you said, build another
>layer encapsulating OpenSocial services and other services.
I think we need to make a decision as to whether Rave is going to be an
OpenSocial container that can render W3C widgets or is a widget mashup
engine with support for OpenSocial, W3C and other widget frameworks. This
decision will help us decide to what degree we depend on Shindig.
My current thinking is that Rave manages the core data (people, widgets,
pages, etc) and it gets re-exposed via the rendering engines. This means
you *could* deploy rave with no OpenSocial support and only W3C or
vice-versa.
>Above considerations are based on my knowledge about gadgets and
>OpenSocial. To support other types of widgets (e.g. W3C widget),
>probably more careful investigation is required.
>
>
>@Ate
>I talked with Marlon about data access component. Besides what you
>proposed (writing separate database access module), another strategy
>is that all database accesses, not only OpenSocial data accesses but
>also RAVE portal data acceses, are delegated to Shindig. For example,
>when user logs in RAVE portal, a request is sent to portal to get
>user's layout data. This request is received by portal and data
>access request is sent to Shindig. In other words, all data is
>managed by Shindig. To do so, OpenSocial data objects need to be
>extended to include RAVE portal data. For example, Person object can
>be extended to include 1) the user's portal layout data 2) the user's
>gadget preferences 3) more authenticated information, etc. It may or
>may not work well in reality. Just my (and Marlon's) 0.02 cents.
>
>
>Gerald
>
>On Mon, May 16, 2011 at 1:22 PM, Franklin, Matthew B.
><mf...@mitre.org> wrote:
>> On 5/13/11 11:33 AM, "Ate Douma" <at...@douma.nu> wrote:
>>
>>>Another benefit I forgot to add of creating a separate database access
>>>module
>>>would be that it allows creating other (portal independent) applications
>>>like an
>>>admin console for maintenance purposes or reporting solutions which
>>>don't
>>>need
>>>and possibly even are undesired to be integrated directly in the portal.
>>>Of course, for that we could also add an additional REST or RPC services
>>>layer
>>>within the portal (and we also can do both), but for low-level/admin
>>>usage a
>>>direct database access layer probably might be easier and preferred.
>>
>> This sounds similar to the approach that Jesse took internally for OSEC
>> (unless I am misreading the comments). He created a backend person REST
>> service that both Shindig and OSEC connect to.
>>
>> Given that Rave is going to be integrating multiple widget renderers, it
>> might make sense to build a central component that manages the data
>>store
>> for information (like person) that is common amongst all components,
>>then
>> provide an API for access by Shindig, portal and Wookie.
>>
>>>
>>
>>
Re: OpenSocial Person related SPI implementation
Posted by "Zhenhua (Gerald) Guo" <je...@gmail.com>.
Just committed code for initial SPI implementation (JPA is used).
Based on response in previous emails, I put the code into
rave-shindig. Current user table is not used at all because it's more
a user management oriented object. Instead a table "person" (with some
other tables) is created for storing information of OpenSocial
persons.
@Matt
It's a good idea to create unified REST services accessed by both
Shindig and portal. However, if Opensocial REST services are enough
(don't need other services), the unified REST service layer may not be
necessary. If we need more services than those provided by OpenSocial
spec, we can either extend OpenSocial, or as you said, build another
layer encapsulating OpenSocial services and other services.
Above considerations are based on my knowledge about gadgets and
OpenSocial. To support other types of widgets (e.g. W3C widget),
probably more careful investigation is required.
@Ate
I talked with Marlon about data access component. Besides what you
proposed (writing separate database access module), another strategy
is that all database accesses, not only OpenSocial data accesses but
also RAVE portal data acceses, are delegated to Shindig. For example,
when user logs in RAVE portal, a request is sent to portal to get
user's layout data. This request is received by portal and data
access request is sent to Shindig. In other words, all data is
managed by Shindig. To do so, OpenSocial data objects need to be
extended to include RAVE portal data. For example, Person object can
be extended to include 1) the user's portal layout data 2) the user's
gadget preferences 3) more authenticated information, etc. It may or
may not work well in reality. Just my (and Marlon's) 0.02 cents.
Gerald
On Mon, May 16, 2011 at 1:22 PM, Franklin, Matthew B.
<mf...@mitre.org> wrote:
> On 5/13/11 11:33 AM, "Ate Douma" <at...@douma.nu> wrote:
>
>>Another benefit I forgot to add of creating a separate database access
>>module
>>would be that it allows creating other (portal independent) applications
>>like an
>>admin console for maintenance purposes or reporting solutions which don't
>>need
>>and possibly even are undesired to be integrated directly in the portal.
>>Of course, for that we could also add an additional REST or RPC services
>>layer
>>within the portal (and we also can do both), but for low-level/admin
>>usage a
>>direct database access layer probably might be easier and preferred.
>
> This sounds similar to the approach that Jesse took internally for OSEC
> (unless I am misreading the comments). He created a backend person REST
> service that both Shindig and OSEC connect to.
>
> Given that Rave is going to be integrating multiple widget renderers, it
> might make sense to build a central component that manages the data store
> for information (like person) that is common amongst all components, then
> provide an API for access by Shindig, portal and Wookie.
>
>>
>
>
Re: OpenSocial Person related SPI implementation
Posted by Scott Wilson <sc...@gmail.com>.
On 13 May 2011, at 16:33, Ate Douma wrote:
> On 05/13/2011 05:04 PM, Ate Douma wrote:
>> On 05/11/2011 09:14 PM, Zhenhua (Gerald) Guo wrote:
>>> There are two ways how Shindig SPIs are implemented.
>>
>> From a practical POV, I would expect using database access from Shiding for now
>> should also be easier/quicker to implement (assuming the common database access
>> logic is factored out in a separate module).
>> And, as this database access layer is needed by the portal already anyway, there
>> is little effort lost if we later on would decide to implement and leverage
>> OpenSocial services from the portal instead.
>
> Another benefit I forgot to add of creating a separate database access module would be that it allows creating other (portal independent) applications like an admin console for maintenance purposes or reporting solutions which don't need and possibly even are undesired to be integrated directly in the portal.
> Of course, for that we could also add an additional REST or RPC services layer within the portal (and we also can do both), but for low-level/admin usage a direct database access layer probably might be easier and preferred.
>
>>
>> Anyone else with an opinion or feedback?
A REST API does provide some flexibility. (Apache Wink is quite nice for generating a REST APIs.)
>>
>> Ate
>>
>>>
>>>
>>> Gerald
>>>
>>> On Tue, May 10, 2011 at 11:42 PM, Zhenhua (Gerald) Guo<je...@gmail.com> wrote:
>>>> I just created a JIRA sub-task for OpenSocial Person related SPI implementation.
>>>> The Person object is specified in OpenSocial spec 2.0
>>>> http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Person.
>>>> In RAVE, we have already had User class. However, our existing User
>>>> class serves different purposes than OpenSocial Person object.
>>>> I am considering implementing Person related SPIs, at least GetPerson
>>>> SPI, if nobody else is implementing it. In the first step, I will use
>>>> our existing User class and expose basic user information (e.g.
>>>> username) to Shindig. Then I will extend User class (or write a
>>>> completely new class) to add more fields required by OpenSocial Person
>>>> data structure/model.
>>>> Any comments on this? Is the proposed implementation strategy appropriate?
>>>>
>>>> Thanks,
>>>> Gerald
>>>>
>>
>
Re: OpenSocial Person related SPI implementation
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 5/13/11 11:33 AM, "Ate Douma" <at...@douma.nu> wrote:
>Another benefit I forgot to add of creating a separate database access
>module
>would be that it allows creating other (portal independent) applications
>like an
>admin console for maintenance purposes or reporting solutions which don't
>need
>and possibly even are undesired to be integrated directly in the portal.
>Of course, for that we could also add an additional REST or RPC services
>layer
>within the portal (and we also can do both), but for low-level/admin
>usage a
>direct database access layer probably might be easier and preferred.
This sounds similar to the approach that Jesse took internally for OSEC
(unless I am misreading the comments). He created a backend person REST
service that both Shindig and OSEC connect to.
Given that Rave is going to be integrating multiple widget renderers, it
might make sense to build a central component that manages the data store
for information (like person) that is common amongst all components, then
provide an API for access by Shindig, portal and Wookie.
>
Re: OpenSocial Person related SPI implementation
Posted by Ate Douma <at...@douma.nu>.
On 05/13/2011 05:04 PM, Ate Douma wrote:
> On 05/11/2011 09:14 PM, Zhenhua (Gerald) Guo wrote:
>> There are two ways how Shindig SPIs are implemented.
>> 1) Implementation of Shindig SPI directly accesses RAVE database to
>> get whatever information it needs.
>> Disadvantages:
>> - Shindig and RAVE portal must be placed on the same machine.
> Why can't we access the Rave database remotely?
>
>> - Database access code may be duplicated in both Shindig SPI
>> implementation and RAVE code.
> Duplication of the code is undesirable, but if we package the database access
> logic as a separate module it can be "shared" or used by both.
>
>>
>> 2) RAVE portal exposes OpenSocial services (e.g. GetPerson, GetAlbums)
>> and implementation of Shindig SPI calls them (instead of accessing
>> database directly).
>> Advantages
>> - Shindig and RAVE portal can be run on separate machines
>> - Database access code is maintained in only one place.
>> Disadvantages:
>> - Security concern may arise.
>>
>> Any comments about which one is better?
>
> Another tough question :)
>
> Both do have advantages and disadvantages, but from a scalability POV my
> preference probably would go to the first one. That way only the portal is
> dependent on Shindig (or other widget containers) but not simultaneous also the
> other way around.
>
> One (very large scale) scenario I can envision for instance is leveraging
> sharded NoSQL database instances where (only) subsets of users a served by a
> particular Shindig instance and then only need a (near) local database with only
> data for that subset. If however the Shindig needs to access the portal instance
> it either forces all this load to one portal or we will have to devise our own
> sharding logic. I'd prefer delegating such functionality to backend services
> which already are good at that (e.g. databases).
>
> But of course, more criteria might need to be taken in consideration to decide
> on the right course here.
>
> From a practical POV, I would expect using database access from Shiding for now
> should also be easier/quicker to implement (assuming the common database access
> logic is factored out in a separate module).
> And, as this database access layer is needed by the portal already anyway, there
> is little effort lost if we later on would decide to implement and leverage
> OpenSocial services from the portal instead.
Another benefit I forgot to add of creating a separate database access module
would be that it allows creating other (portal independent) applications like an
admin console for maintenance purposes or reporting solutions which don't need
and possibly even are undesired to be integrated directly in the portal.
Of course, for that we could also add an additional REST or RPC services layer
within the portal (and we also can do both), but for low-level/admin usage a
direct database access layer probably might be easier and preferred.
>
> Anyone else with an opinion or feedback?
>
> Ate
>
>>
>>
>> Gerald
>>
>> On Tue, May 10, 2011 at 11:42 PM, Zhenhua (Gerald) Guo<je...@gmail.com> wrote:
>>> I just created a JIRA sub-task for OpenSocial Person related SPI implementation.
>>> The Person object is specified in OpenSocial spec 2.0
>>> http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Person.
>>> In RAVE, we have already had User class. However, our existing User
>>> class serves different purposes than OpenSocial Person object.
>>> I am considering implementing Person related SPIs, at least GetPerson
>>> SPI, if nobody else is implementing it. In the first step, I will use
>>> our existing User class and expose basic user information (e.g.
>>> username) to Shindig. Then I will extend User class (or write a
>>> completely new class) to add more fields required by OpenSocial Person
>>> data structure/model.
>>> Any comments on this? Is the proposed implementation strategy appropriate?
>>>
>>> Thanks,
>>> Gerald
>>>
>
Re: OpenSocial Person related SPI implementation
Posted by Ate Douma <at...@douma.nu>.
On 05/11/2011 09:14 PM, Zhenhua (Gerald) Guo wrote:
> There are two ways how Shindig SPIs are implemented.
> 1) Implementation of Shindig SPI directly accesses RAVE database to
> get whatever information it needs.
> Disadvantages:
> - Shindig and RAVE portal must be placed on the same machine.
Why can't we access the Rave database remotely?
> - Database access code may be duplicated in both Shindig SPI
> implementation and RAVE code.
Duplication of the code is undesirable, but if we package the database access
logic as a separate module it can be "shared" or used by both.
>
> 2) RAVE portal exposes OpenSocial services (e.g. GetPerson, GetAlbums)
> and implementation of Shindig SPI calls them (instead of accessing
> database directly).
> Advantages
> - Shindig and RAVE portal can be run on separate machines
> - Database access code is maintained in only one place.
> Disadvantages:
> - Security concern may arise.
>
> Any comments about which one is better?
Another tough question :)
Both do have advantages and disadvantages, but from a scalability POV my
preference probably would go to the first one. That way only the portal is
dependent on Shindig (or other widget containers) but not simultaneous also the
other way around.
One (very large scale) scenario I can envision for instance is leveraging
sharded NoSQL database instances where (only) subsets of users a served by a
particular Shindig instance and then only need a (near) local database with only
data for that subset. If however the Shindig needs to access the portal instance
it either forces all this load to one portal or we will have to devise our own
sharding logic. I'd prefer delegating such functionality to backend services
which already are good at that (e.g. databases).
But of course, more criteria might need to be taken in consideration to decide
on the right course here.
From a practical POV, I would expect using database access from Shiding for now
should also be easier/quicker to implement (assuming the common database access
logic is factored out in a separate module).
And, as this database access layer is needed by the portal already anyway, there
is little effort lost if we later on would decide to implement and leverage
OpenSocial services from the portal instead.
Anyone else with an opinion or feedback?
Ate
>
>
> Gerald
>
> On Tue, May 10, 2011 at 11:42 PM, Zhenhua (Gerald) Guo<je...@gmail.com> wrote:
>> I just created a JIRA sub-task for OpenSocial Person related SPI implementation.
>> The Person object is specified in OpenSocial spec 2.0
>> http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Person.
>> In RAVE, we have already had User class. However, our existing User
>> class serves different purposes than OpenSocial Person object.
>> I am considering implementing Person related SPIs, at least GetPerson
>> SPI, if nobody else is implementing it. In the first step, I will use
>> our existing User class and expose basic user information (e.g.
>> username) to Shindig. Then I will extend User class (or write a
>> completely new class) to add more fields required by OpenSocial Person
>> data structure/model.
>> Any comments on this? Is the proposed implementation strategy appropriate?
>>
>> Thanks,
>> Gerald
>>
Re: OpenSocial Person related SPI implementation
Posted by "Zhenhua (Gerald) Guo" <je...@gmail.com>.
There are two ways how Shindig SPIs are implemented.
1) Implementation of Shindig SPI directly accesses RAVE database to
get whatever information it needs.
Disadvantages:
- Shindig and RAVE portal must be placed on the same machine.
- Database access code may be duplicated in both Shindig SPI
implementation and RAVE code.
2) RAVE portal exposes OpenSocial services (e.g. GetPerson, GetAlbums)
and implementation of Shindig SPI calls them (instead of accessing
database directly).
Advantages
- Shindig and RAVE portal can be run on separate machines
- Database access code is maintained in only one place.
Disadvantages:
- Security concern may arise.
Any comments about which one is better?
Gerald
On Tue, May 10, 2011 at 11:42 PM, Zhenhua (Gerald) Guo <je...@gmail.com> wrote:
> I just created a JIRA sub-task for OpenSocial Person related SPI implementation.
> The Person object is specified in OpenSocial spec 2.0
> http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Person.
> In RAVE, we have already had User class. However, our existing User
> class serves different purposes than OpenSocial Person object.
> I am considering implementing Person related SPIs, at least GetPerson
> SPI, if nobody else is implementing it. In the first step, I will use
> our existing User class and expose basic user information (e.g.
> username) to Shindig. Then I will extend User class (or write a
> completely new class) to add more fields required by OpenSocial Person
> data structure/model.
> Any comments on this? Is the proposed implementation strategy appropriate?
>
> Thanks,
> Gerald
>