I'm inlining responses to two separate emails... one from Ryan and one from stpeter... enjoy.
Ryan Hart said: > For example, please explain in more detail how the presence bcc markup > could > be used to solve this problem. I understand that I could create a > component > to receive these messages, and I have played around with this some. Sure, > this component could capture all the presence information and save it in a > database. But, then what? I already have an xdb component, I would really > like to just return these connected users as part of the roster query > response. But that doesn't work... sure they'll show up in the clients > roster, but the presence will never be known because the server won't > receive a matching 'from' roster subscription for these jids. I would like > presence to be handled automatically by jabber as if there was a 2-way > 'both' subscription between these users. I should also mention that > presence > alone is not sufficient for our client. Our jids use numeric user_id > values > from our database to be unique... we always display the roster "name" > attribute which is not part of the presence message. The way to do this is fairly simple... when I use presence bcc, all presence packets are sent to my component, so I can create a table (in memory, or in a database -- doesn't matter) that has Jids and their current presence. Assume here's what we got: 1) Users [EMAIL PROTECTED]/blah and [EMAIL PROTECTED]/blah are online, and available. 2) User [EMAIL PROTECTED] was online, but has since got "unavailable" -- no reason to clog up my memory with an entry for him. 3) User [EMAIL PROTECTED]/blah has just come online, and I've received presence in my component. So... my component just received a presence packet that looks like <presence from="[EMAIL PROTECTED]/blah" to="bcc.mydomain.com" />. First things first, I add an entry for [EMAIL PROTECTED]/blah to my table. Next up, I send out presence packets to the other users online... so my component sends: <presence from="[EMAIL PROTECTED]/blah" to="[EMAIL PROTECTED]/blah" /> <presence from="[EMAIL PROTECTED]/blah" to="[EMAIL PROTECTED]/blah" /> <presence from="[EMAIL PROTECTED]/blah" to="[EMAIL PROTECTED]/blah" /> The last one's probably not necessary, and I could have written my component to not send it -- but it really doesn't have any negative effects. Why this works...? In the open source jabberd (and in the commercial implementation by Jabber, Inc.) external components are "trusted" -- which means that the server doesn't force authenticity in their "from" Jids -- this isn't true for client connections. So there you are... you have now have a way to send out these presence updates, without any protocol extension. Best of all... this stays solely within the realm of your server, meaning that external type="pro..." or that <pro...> element don't get populated out to contacts that aren't on my server. And you have this information out in this external component, so if you choose to write it to a database, you can do web-based availability ala ICQ. You can even provide users with the ability to configure whether they want their presence broadcast, by sending some other protocol to this component. Hope that helps... Peter Saint-Andre said: > Second, you can't just add new presence types to the protocol. :-) This > protocol is now in IETF Last Call. Just as you can't add a new HTTP > method because you think PUT and GET are not enough, you can't add new > presence types willy-nilly. As a protocol junky, I felt it was necessary to step up and correct this wrong. From section 9 of RFC 2616: The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers. So you *can* add new methods, but you can't assume that other clients, server, etc. will listen to 'em. It should be noted, however, that since XMPP is defined by a series of schema's, that a validating implementation of the protocol would likely boot you for sending type="pro..." (as well as type="invisible"). Cheers, bs. _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
