On 8 Apr 2011, at 15:02, Niels van Dijk wrote: > Hi Scott, > > Did you have a look at the the spaces proposal for opensocial 2.0/3.0? > <http://docs.opensocial.org/display/OSD/Space+Proposal> This seems to > point in the same direction as what you are aiming at.
Yes, its definitely talking about the same sort of object (but see below...) > We currenlty have similair stuff in our portal, which we called 'tabs'. > these bind together gadets, users and groups in one collaboration > 'space'. The tab is sharable between users and usergroups, but not yet > between applications (as there is not standard way of doing that). See > <http://www.surfmedia.nl/app/video/PeQtSWVfmAVVCdgISsdxiII0/play?format_id=b2bPgRmGNXrASYXWfX8gpU1j&mode=object> > for a (Dutch) demo. Yep, thats very much the type of solution we're after. We're particularly interested in adding inter-widget messaging and telecoms APIs to this kind of mashup. Making these fully portable across containers - so being able to take a collab space structure from one environment and then add it to Sharepoint or LifeRay for use by another team/company would be great. > Having such functionalities in a standardized way would be very cool, > but I feel, especially with the idea of also being able to consume such > a space in other platforms, that this should be a thing supported by a > container like shindig, and therefor be part of the opensocial spec, in > stead of solving this problem by turning a 'presentation layer' like > Rave into a 'provider'. I think Shindig's primary role is to provide gadgets, not to manage workspaces I think it makes more sense to treat this as an aspect of the layout/presentation layer than the widget container. The OpenSocial spaces extension proposal is I think is for doing the same thing we do in Wookie at the moment, which is allowing applications to identify the context a widget is being created for. Its not about having Shindig manage or render the spaces itself - the space is defined by the "presentation layer" as part of its own model (i.e. a Rave Region). > > Cheers, > Niels > > On 04/07/2011 07:34 PM, Scott Wilson wrote: >> Hi everyone, >> >> I'm working on a project at the moment which concerns creating "workspaces" >> containing mashups of multiple widgets and inter-widget messaging that can >> be embedded in other applications (such as portals, CMS, intranets etc) and >> also exported and shared. I've been wondering how this could fit with Rave >> as in many ways its quite similar - and it would be far better for us and >> our consortium partners to contribute to Rave rather than to create another >> project. >> >> I'm currently thinking we could do this in two ways: >> >> 1. Have "Rave Region providers" as well as "Rave Widget providers". >> >> So in this approach, a similar mechanism the one allowing Shindig to provide >> OpenSocial gadgets for Rave Widgets also applies to a Rave Region - so an >> external provider can hook in a complete Region which can itself contain >> widgets. >> >> 2. Have Rave act as a Plug-in for other platforms >> >> The alternative is to enable Rave to be plugged in to other applications, to >> provide a Region or a Page that can be rendered for and embedded in other >> platforms like Drupal, Jetspeed, LifeRay etc. So in this scenario Rave is >> behaving like a kind of standalone mashup layout engine. I think this would >> be really nice, the most complicated part being how you'd wire up the SPI. >> >> Finally, we could always have it both ways which provides for the intriguing >> possibility of publishing regions from one Rave instance through another! >> >> S
