Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
On Wed, May 30, 2012 at 5:49 AM, Lance Stout wrote: >> I suppose there is nothing stopping you from subscribing directly to a >> components presence. > > Right, components can do everything a client can do, including sending > presence and handling presence subscriptions (after all, that's part of what > makes gateways work). The distinction, aside from the extra control over > JIDs, is that the server will not maintain the roster for you, so if you want > or need one you have to implement and maintain it yourself in the component. > The roster in the end is just a table of subscription mappings. > >> I haven't tried this as I have been relying on OpenFire. The OpenFire gui >> doesn't provide the means to setup a roster for a component. I will need to >> try to subscribe to it directly and see how that works > > > Again, that is because you would need to implement that inside your > component. Technically you could even hook into the server's roster storage > if it lends itself easily to the task, but it still requires that the > component manages the integration. > > Another difference is that you will probably also want to do presence probing > to receive initial presence updates, which is another thing that the server > does on behalf of clients that it does not do for components. > > For all of these reasons, in SleekXMPP we ended up adding a complete > multi-JID roster backend so components could easily have their own rosters. > > The only gotcha I've encountered with component presence and current server > implementations is that if the component crashes or goes offline, the server > will not broadcast unavailable presence like with clients. That can leave > contacts' views of the component's presence in odd states. The solution for > that, of course, is to have clustering, etc so that it doesn't matter. There's also that if what you need is a JID that has rosters, server-managed presence, etc., what you're describing is really a client. Many uses of components could just as well be served by writing a client. Not all, by any stretch, but components shouldn't be the automatic go-to for writing a service. /K
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
> I suppose there is nothing stopping you from subscribing directly to a > components presence. Right, components can do everything a client can do, including sending presence and handling presence subscriptions (after all, that's part of what makes gateways work). The distinction, aside from the extra control over JIDs, is that the server will not maintain the roster for you, so if you want or need one you have to implement and maintain it yourself in the component. The roster in the end is just a table of subscription mappings. > I haven't tried this as I have been relying on OpenFire. The OpenFire gui > doesn't provide the means to setup a roster for a component. I will need to > try to subscribe to it directly and see how that works Again, that is because you would need to implement that inside your component. Technically you could even hook into the server's roster storage if it lends itself easily to the task, but it still requires that the component manages the integration. Another difference is that you will probably also want to do presence probing to receive initial presence updates, which is another thing that the server does on behalf of clients that it does not do for components. For all of these reasons, in SleekXMPP we ended up adding a complete multi-JID roster backend so components could easily have their own rosters. The only gotcha I've encountered with component presence and current server implementations is that if the component crashes or goes offline, the server will not broadcast unavailable presence like with clients. That can leave contacts' views of the component's presence in odd states. The solution for that, of course, is to have clustering, etc so that it doesn't matter. Lance smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
Understood. I may take the time to look at the Jabber Component XEP a bit more and see about fleshing it out some. The XSD shows presence but it doesn't really discuss how presence is shared. For client's, presence is related to a roster. I suppose there is nothing stopping you from subscribing directly to a components presence. I haven't tried this as I have been relying on OpenFire. The OpenFire gui doesn't provide the means to setup a roster for a component. I will need to try to subscribe to it directly and see how that works. Todd Herman -Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Peter Saint-Andre Sent: Tuesday, May 29, 2012 10:38 PM To: XMPP Standards Subject: Re: [Standards] UPDATED: XEP-0267 (Server Buddies) On 5/29/12 8:33 PM, Todd Herman wrote: > Question: Can this extension (XEP-00267) used with Components? The > ability for components to send and receive presence is important to us > but the Jabber Component extension doesn't really expand on this much. > I believe they can receive presence information as, at least with > OpenFire, you can add a component to a roster but you can't do the > opposite (since components don't have an account or a roster). I am > wondering if the concepts discussed in 0267 could apply to a component > also. Thoughts? Any entity can share presence information with any other entity. So, yes, an add-on component could share presence with other components, with the server it's connected to, with users of the component, etc. For purposes of XEP-0267 I was interested only in server-to-server presence to used in improving federation of core XMPP servers, not components. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
On 5/29/12 8:33 PM, Todd Herman wrote: > Question: Can this extension (XEP-00267) used with Components? The > ability for components to send and receive presence is important to > us but the Jabber Component extension doesn't really expand on this > much. I believe they can receive presence information as, at least > with OpenFire, you can add a component to a roster but you can't do > the opposite (since components don't have an account or a roster). I > am wondering if the concepts discussed in 0267 could apply to a > component also. Thoughts? Any entity can share presence information with any other entity. So, yes, an add-on component could share presence with other components, with the server it's connected to, with users of the component, etc. For purposes of XEP-0267 I was interested only in server-to-server presence to used in improving federation of core XMPP servers, not components. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
Question: Can this extension (XEP-00267) used with Components? The ability for components to send and receive presence is important to us but the Jabber Component extension doesn't really expand on this much. I believe they can receive presence information as, at least with OpenFire, you can add a component to a roster but you can't do the opposite (since components don't have an account or a roster). I am wondering if the concepts discussed in 0267 could apply to a component also. Thoughts? -Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of XMPP Extensions Editor Sent: Tuesday, May 29, 2012 9:16 PM To: standards@xmpp.org Subject: [Standards] UPDATED: XEP-0267 (Server Buddies) Version 0.5 of XEP-0267 (Server Buddies) has been released. Abstract: This specification defines a convention for presence subscriptions between XMPP servers. Changelog: Corrected several examples and points in the text. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0267/diff/0.4/vs/0.5 URL: http://xmpp.org/extensions/xep-0267.html
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
On 12/12/11 2:10 PM, Kim Alvefur wrote: > On Mon, 2011-12-12 at 20:36 +, XMPP Extensions Editor wrote: >> Changelog: Updated ad-hoc command with field for the sending server; >> added XMPP Registrar Considerations. (psa) > > What about the 'to' attribute of the ? I suppose that might do it...
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
On Mon, 2011-12-12 at 20:36 +, XMPP Extensions Editor wrote: > Changelog: Updated ad-hoc command with field for the sending server; > added XMPP Registrar Considerations. (psa) What about the 'to' attribute of the ? -- Kim Alvefur
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
On 12/10/11 2:18 AM, Kim Alvefur wrote: > I had some thougts about using PEP in combination with this for > sharing things like peer server certs seen, and incident reports. My current plan is to use this as the basis for automating data gathering for http://xmpp.org/resources/public-services/ (along with server vCards and disco features for "I'm a public server" and "I support jabber:iq:register"). More on that soon. :) But yes, once we have server buddies we can use PEP for some interesting features. /psa
Re: [Standards] UPDATED: XEP-0267 (Server Buddies)
Hi I had some thougts about using PEP in combination with this for sharing things like peer server certs seen, and incident reports. - Original message - > Version 0.2 of XEP-0267 (Server Buddies) has been released. > > Abstract: This specification defines a convention for presence > subscriptions between XMPP servers. > > Changelog: Defined ad-hoc command for admin generation of outbound > presence subscription; added security considerations. (psa) > > Diff: http://xmpp.org/extensions/diff/api/xep/0267/diff/0.1/vs/0.2 > > URL: http://xmpp.org/extensions/xep-0267.html >
