[Opensim-dev] XMPP Support in OSSL

[dirk husemann]

Aldon Hynes wrote:
> The focus on using XMPP as the chat glue is what is especially 
> attractive to me.  It seems as if there are several interesting 
> aspects to that. 
>  
> The simplest being the suggestion from dirk.
>
>     * JID: firstname.lastname at userserver
>     * roster == friends
>
> Beyond that, tying it to groups.
>
>     * JID: groupname at userserver/group <mailto:groupname at userserver/group>
>     * roster == group members
>
> Another interesting aspect is tying it to location.  e.g.
>
>     * JID: sim/x/y/z at userserver/location
>       <mailto:sim/x/y/z at userserver/location>
>     * roster == nearby avatars
>
> This could also be done to support channels.  e.g.
>
>     * JID: sim/x/y/z/channel at userserver/location
>       <mailto:sim/x/y/z/channel at userserver/location>
>
> could be used for other channels.  With that 
> sim/x/y/z/0 at userserver/location 
> <mailto:sim/x/y/z/0 at userserver/location> would be the same as 
> sim/x/y/z at userserver/location <mailto:sim/x/y/z at userserver/location>
> Other areas that this would help with.  The debug channel would then 
> be available via XMPP providing the sort of debugging that dirk 
> suggested in a previous email.
>  
> This would also be of great use for people building external systems 
> to connect via XMPP.
>  
> Another piece of functionality that would be very interesting would be 
> to expose search functionality via XMPP e.g.
>
>     * JID: searchstring at userserver/searchtype
>       <mailto:searchstring at userserver/searchtype>
>     * roster = search results
>
> The search type could be optional.  If it is omitted, it would imply 
> all.  It could be people or places returning the user JIDs as the 
> roster, as decribed above for people searches or the location JIDs as 
> described above for places (or popularplaces) searches.  For all, it 
> could return a mix of both people and locations.
>  
> Objects could also have their own JID
>
>    *
>       JID: UUID at userserver/object <mailto:UUID at userserver/object>
>
> For people, this could provide an alternative way of contacting the 
> person, but mostly, it would be direct communications with an object.  
> I'm not sure what an object should return as its roster.
>  
> Also, following Stefan's suggestion, there could be extentions as 
> necessary as created by the programmers. e.g
>
>     * JID: userfield at userserver/userextention
>       <mailto:userfield at userserver/userextention>
>
> To be defined by the programmer as necessary.
>  
> I don't know XMPP well enough to know if there is any sort of self 
> discovery mechanism, If there isn't, having some sort of
>
>     * JID: directory at userserver/directory
>       <mailto:directory at userserver/directory>
>
> type functionality to list the different methods available via XMPP 
> would be a nice feature, particularly when user extentions have been 
> added.
there is, the DISCO mechanism. haven't played with it yet, though it 
does look fairly interesting ;-)

-- 
dr dirk husemann, pervasive computing, ibm zurich research lab
--- hud at zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080128/edac6d4c/attachment-0001.html>