Hi guys,
We've always been very interested in communities and we've worked on
the proto xep you're talking about. The first approach we've taken and
the one we're currently using is a bit different from the one
described in the proto-xep. Main difference is that the community
doesn't have a presence subscription to the user, which in the end
means that there is no server dependency to it. Community members are
simply room members. You can then play with muc administration to
define either an open or closed community. Since the room doesn't have
a sub to the client's presence this also mean that the client will
have to manually connect to the community.
We've added extra features such as join a community and receive other
user's presence but our presence is not broadcasted. (we've done that
using which roles broadcast presence in the room) and we've also added
muc privacy lists.
If you're interested I can send the doc we have on this or send you
the stanza workflow.
Also I think the approach of the proto xep is really interesting
because it considers "community entity" and "client entity" almost
the same. By adding presence to the "community entity" and adding
roster capabilities to the "community entity" as well we can build
really interesting by reusing current protocols such as PEP to add
community profile, community news. PEP could also be used to discover
files attached to the community, wiki.... the pep would be the
community shared space. We can also build community conferences by
making a single one-to-one jingle call to the community entity. The
community would then have the capability to do simple conferencing on
top of that....
-Yann
On 28 oct. 08, at 04:32, Boyd Fletcher wrote:
I think there a big need to have consistent way of:
structuring “shared spaces” in a bldg/floor/room layout
attaching multimedia (audio, video, whiteboard, presentations,
voting/surveys, etc....) to a MUC to create a “shared space”
attaching asynchronous media (wiki, file storage, blogs, portal,
etc...) to a “shared space”
basically in order to move XMPP beyond just a chat standard we need
to look at the “shared spaces” concept and figure out how to do it
one better than all the proprietary collaboration systems. This was
a big part of why we are creating a whiteboarding/presentation proto-
XEP. For the asynchronous stuff its pretty much HTTP(s) and WebDAV
and for audio/video its Jingle. But the key is everything builds
around the MUC and “shared space” would extend the MUC’s
configuration with additional fields that provide URLs or JIDs for
the “share space” services.
if you integrate XMPP with a SSO solution than it really becomes a
viable idea.
boyd
On 10/27/08 12:25 PM, "Dave Cridland" <[EMAIL PROTECTED]> wrote:
Oh, and before I forget, someone also mentioned communities in jdev a
while back (perhaps the week before last), and a customer was talking
abut the desire for something fairly similar.
I looked at the communities proto-xep, and it looks... curiously
compelling, but perhaps too complicated. I think we could actually do
communities entirely client-side, using MUC in order to both share
presence bilaterally with other community members, and also broadcast
messages to the community, in a curious and slightly microbloggery
way - effectively, it's just a different interface on MUC, rather
than a different protocol on the wire.
Is there any interest in specifying something like this, and, more
importantly, would client authors consider implementing something
like this?
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
