-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/28/09 8:35 PM, Nathan Fritz wrote: > On Sep 28, 2009, at 5:33 PM, Peter Saint-Andre <[email protected]> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/25/09 8:57 AM, Nathan Fritz wrote: >>> On Sep 25, 2009, at 4:33 AM, Paul Witty <[email protected]> wrote: >>> >>>> Is there documented anywhere the rules of how presence information >>>> works with components? e.g. can components subscribe to clients' >>>> presence information, or send presence probes etc. Likewise, can a >>>> component publish presence, and clients subscribe to its presence, but >>>> including things like publishing presence for >>>> component.xmppserver.com, and clients getting that presence for >>>> [email protected]? >>>> >>> >>> A component is just like a server jid. Presence can be routed to and >>> from, subscriptions can be made. Probes will likely need to be sent and >>> are likely to be recieved. There is no session management, so you'll >>> have to implement roster storage yourself or fake it. >>> >>> And yes, you can send and recieve from any user and resource for your >>> component's domain. >>> >>> If you look at a transport component, they do all of these things. >> >> Right. >> >> Granted, this kind of thing is not typically used by MUC services >> (handled at the room level via directed presence) or whatever, but >> nothing in the specs forbids it and IMHO it's Smart to use presence >> everywhere it will solve an interesting problem. :) > > Wait, why are you bringing up MUC?
Sorry, my sentence was poorly formed. I meant that people don't typically presence-enable your interaction with a MUC service as opposed to a MUC room. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrBelcACgkQNL8k5A2w/vzbPQCghaYRTHSd7ZKfBw9f8Iit7g52 qeEAn1BD9W8tOojv2Vq2X29Ul7kgz3X4 =KlFs -----END PGP SIGNATURE-----
