Is Rave a good fit?

[Nolan Darilek <no...@thewordnerd.info>]

So I've gotten the vanilla portal project up and running, and am slowly 
trying to make it my own. I've also been reading the various OpenSocial 
specs, and am trying to discover if Rave is a good fit for this project.

A friend and I are working on a technology platform for housing 
cooperatives. My vision for the platform is as sort of a mini social 
network. Users sign up or are invited, and join groups for their house. 
They then have access to a series of apps in a bunch of domains related 
to managing their house. A labor-scheduling app aggregates user 
preferences for what sorts of tasks they like/dislike, their 
availability, etc. and creates the best schedule which is displayed as a 
calendar. A menu-planning/shopping-list app arranges recipes on a 
separate calendar, adding their ingredients to a shared shopping list. 
Over time, additional apps are built and plugged into this core. 
Additionally, since houses have their own unique requirements sometimes, 
someone may wish to write their own custom app and make it available on 
our site. It'd be nice if the platform didn't impose language 
requirements. I really dislike Java for instance, but would love to 
develop my apps in Scala and Lift, perhaps using MongoDB as the 
datastore. Letting other folks plug their Node.js apps in would also be 
cool.

It looks like OpenSocial might be a good fit for this use case. Am I 
right? Each module could be built as a separate gadget, and Rave becomes 
the dashboard which aggregates them all.

If so, how much would I need to tweak the portal code itself? My 
studying of the OpenSocial spec seems to indicate that gadgets can be 
displayed on specific "views." So if I want people to be able to sign up 
for free, to create groups, and to use those groups as mechanisms to 
associate their members with various app contexts, then I can implement 
most of that functionality as a gadget on the group's view without 
touching Rave code? The idea is that each house could be its own group, 
and the labor scheduling gadget could use groups on the Rave site as 
mechanisms for determining which members are eligible for certain lists 
of tasks, etc.

Finally, how limited am I by proxying to OpenSocial gadgets? Lift's 
strengths are its statefulness and its support for comet. This is 
managed through server-side sessions. Are gadgets static, or is there 
some way to ensure that the proxy passes along all AJAX requests and 
honors Lift's long-poll comet mechanism?

Thanks.

RE: Is Rave a good fit?

["Franklin, Matthew B." <mf...@mitre.org>]

Hi Nolan,

Sorry for the late response, most of us were on vacation these last two weeks.

I have responded to your questions inline.

-Matt

>-----Original Message-----
>From: Nolan Darilek [mailto:nolan@thewordnerd.info]
>Sent: Saturday, December 29, 2012 10:47 AM
>To: users@rave.apache.org
>Subject: Is Rave a good fit?
>
>So I've gotten the vanilla portal project up and running, and am slowly
>trying to make it my own. I've also been reading the various OpenSocial
>specs, and am trying to discover if Rave is a good fit for this project.
>
>A friend and I are working on a technology platform for housing
>cooperatives. My vision for the platform is as sort of a mini social
>network. Users sign up or are invited, and join groups for their house.
>They then have access to a series of apps in a bunch of domains related
>to managing their house. A labor-scheduling app aggregates user
>preferences for what sorts of tasks they like/dislike, their
>availability, etc. and creates the best schedule which is displayed as a
>calendar. A menu-planning/shopping-list app arranges recipes on a
>separate calendar, adding their ingredients to a shared shopping list.
>Over time, additional apps are built and plugged into this core.
>Additionally, since houses have their own unique requirements sometimes,
>someone may wish to write their own custom app and make it available on
>our site. It'd be nice if the platform didn't impose language
>requirements. I really dislike Java for instance, but would love to
>develop my apps in Scala and Lift, perhaps using MongoDB as the
>datastore. Letting other folks plug their Node.js apps in would also be
>cool.
>
>It looks like OpenSocial might be a good fit for this use case. Am I
>right? Each module could be built as a separate gadget, and Rave becomes
>the dashboard which aggregates them all.

This is correct.  OpenSocial offers a runtime AJAX proxy (via osapi.http or gadgets.io.makeRequest) that lets you reach backend services written in whatever language or framework you prefer.  

>
>If so, how much would I need to tweak the portal code itself? My
>studying of the OpenSocial spec seems to indicate that gadgets can be
>displayed on specific "views." So if I want people to be able to sign up
>for free, to create groups, and to use those groups as mechanisms to
>associate their members with various app contexts, then I can implement
>most of that functionality as a gadget on the group's view without
>touching Rave code? The idea is that each house could be its own group,
>and the labor scheduling gadget could use groups on the Rave site as
>mechanisms for determining which members are eligible for certain lists
>of tasks, etc.

There currently isn't a "groups" view that is supported by Rave.  At the moment, Rave supports home (default), canvas, profile & customEditPrefs.  Home is the main dashboard view, canvas is the "maximized", profile is the view on the profile page & customEditPrefs is the view used to display your own edit preferences form.  You would need to implement group membership in the database directly or via your own custom repository as we currently don't have a good UI for managing them, though that is something that is an outstanding task that others have expressed interest in.

>
>Finally, how limited am I by proxying to OpenSocial gadgets? Lift's
>strengths are its statefulness and its support for comet. This is
>managed through server-side sessions. Are gadgets static, or is there
>some way to ensure that the proxy passes along all AJAX requests and
>honors Lift's long-poll comet mechanism?

I haven't tried working with comet & Shindig, so I am not sure it would work.  Potentially someone else has tried this...

You can always implement a URL type gadget, which simply sets the iFrame to the target, so you would have a lift app that just knows to render in small form factor and never have to worry about the OpenSocial proxy.

>
>Thanks.