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.
- Is Rave a good fit? Nolan Darilek
-
