Resources have been very helpful and flexible and I think still offer
more possibilities for me. We do a lot with context, since our users
can be in chat rooms for a particular book , but can further
contextualize by being in a book's group room, a different room
entirely for the same book, and the resources are reflecting this
context. I would like to use them for one of their intended purposes,
to connote hardware or platform context, as well. I'd also like to
get out of the confines of our own xmpp server and allow other
domains (jabber or gtalk, for example), but this poses new
authentication problems.
Right now it would be difficult to fold all the "friend"
relationships from the main site into the user rosters, though that
would be better. It would have to be done through a high-level
Javascript API which doesn't exist for us. Besides that, wouldn't it
be better to fold JIDs into "friend profiles" rather than the other
way around? Maybe there is more flexibility and extensibility in the
roster construct than I understand....
Aaron
On Mar 31, 2008, at 5:04 PM, anders conbere wrote:
real JIDs behind aliases,
making it possible to handle our relationships.
This is a problem I call contexting. It's what we do when we have
different persona's on different social networks. Solutions like
pushing all our relationship data into big distributed systems are bad
for people who have multiple contexts, and I've chosen for the most
part to punt on this problem.
However my gut tells me that I'd like to see Resources become more
powerful here.
So that I could login to "The A" with my JID [EMAIL PROTECTED]/The_A
and I could then determine from there how much interplay there was
between my root data and the data stored under "The A"
It would be very interesting to see the overall archetecture we
could use.
Gateways seem to be the most suitable solution for me now, but I'm
eager to
hear other suggestions.
Right my problem is simply that gateways don't invigorate the XMPP
community, they keep all those relationship details locked into the
service on the gateway as opposed to pushing them out into the
distributed XMPP system.
--
Best Regards, Sergey Nazarov
