Hi all,
@Chris: That is correct. It's cross-browser pubsub, realized with XMPP.
@Jack: If you want to try it, you can have a look at a running demo on
the ROLE Sandbox: http://role-sandbox.eu/spaces/iwc. What you basically
need for testing are two open browser instances and two Google accounts
to sign in as different people. For each of the users sign in with their
respective Google account and join the respective space (spaces are
similar to pages; cf. OpenSocial spaces) to become a member (after
having joined you *might* need to reload...). In the ROLE Sandbox, IWC
messages are only transmitted, if the respective user is member of that
space. However, other access models are imaginable, when we think about
the page concept in Rave. Once signed in and being member of the space,
you can play around with the three tech demo example widgets
(Collaborative Painting, navigation on a map, video navigation (select
video, publish seek). If you are interested in even more widgets using
ROLE IWC, there are a couple of examples available in the ROLE Widget
Store. We could give you some pointers...
Dominik
Am 15.01.2013 04:22, schrieb Chris Geer:
On Mon, Jan 14, 2013 at 7:00 PM, Jack Weaver <[email protected]> wrote:
Would this provide an in-session IWC? Or is this cross-session IWC such
that all instances of the widget(s) get the pub/sub message? It looks like
cross-session messaging but I wanted to ask first =)
I assume by "in-session pub/sub" you mean between widgets on one page? That
is already provided by the shindig pubsub2 feature. It sounds like this
will extend that library to provide cross-browser pubsub.
I've used portal frameworks before (one of them, Ozone Widget Framework
here: https://github.com/ozoneplatform/owf) where IWC is in-session only.
This provided app developers some pain such that they had to implement
their own pub/sub so messages would be received between multiple apps
running across different sessions (one such way is to use Atmosphere, here:
https://github.com/Atmosphere/atmosphere). If you do this Andreas, I'd
love to test it out.
---
Jack Weaver
http://jackweaver.net/
661/349-8778
PGP: 6B9C 40C2 1408 97F2 2588
93EC E924 F32C 8AA4 6955
On Sun, Jan 13, 2013 at 8:34 PM, Andreas Guth
<[email protected]>wrote:
Hi,
I'm a developer for the ROLE project [0]. In the project we also use
OpenSocial widgets and a fair amount of Rave code and have created a
system that makes inter-widget-communication work over multiple
machines that we'd (finally) like to contribute to the Rave project,
in particular referring to Rave Epic 25 [1].
Dominik Renzel and Sten Govaerts presented and demoed ROLE
Inter-widget Communication as it is realized in the project's
prototype of a widget based personal learning environment during last
year's Apache Rave Hackathon in Utrecht and were encouraged to move
forward in developing a respective patch. Their slidedeck ([2];
starting from slide 6; slide 14 containing a set of links pointing to
further materials, code samples, demos, etc.) gives an overview of we
did it in ROLE and how developers could use a respective widget API
(notice that this is not restricted to OpenSocial). We hope this is
still of interest for Rave, since I am currently preparing such a
patch.
I already looked through the source and began to port some of our code
but I may need some pointers as to where the IWC code should ideally
go because it looked like most (all?) of your IWC Code is in the
Clients Javascript code.
So, what I would like to add to Rave is:
1. a class that manages the XMPP Server. It would basically make sure
that a pubsub-node is created for every Page and a new JID is created
for every User. I chose to implement this as an IWCService Interface
with a DefaultIWCService alongside the other Service and
DefaultService classes that will handle the XMPP Server but I'm not
sure if there might be a better place for this.
2. make rave create a pubsub-node for each new Page and a JID (+
password) for each new user. I'm not sure where and at what time this
should be done as there are many classes that work with Pages and
Users. My best guess would currently be the "DefaultUserService" and
"DefaultPageService" classes. These would in turn use the IWCService
to do their work.
Any input on this would be appreciated.
Best regards,
Andreas
[0] http://www.role-project.eu/
[1] https://issues.apache.org/jira/browse/RAVE-25
[2]
http://www.slideshare.net/DominikRenzel/role-technologies-a-possible-contribution-to-apache-rave
