On Sat, Dec 19, 2009 at 11:46 PM, Tuomas Koski <koski.tuo...@gmail.com>wrote:
> Hi again, > > (i'll continue my monologue here :) ) > > 2009/12/19 Tuomas Koski <koski.tuo...@gmail.com>: > > Cheers for all, > > > > What do you think what could the best way for an entity "to know" it's > > affiliation state after it has subscribed to a node? > > > > Step 1: entity subscribes to a node: > > > > <iq type='set' > > from='franci...@denmark.lit/barracks' > > to='pubsub.shakespeare.lit' > > id='sub1'> > > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <subscribe > > node='princely_musings' > > jid='franci...@denmark.lit'/> > > </pubsub> > > </iq> > > > > > > Step 2: Service replies with success > > > > <iq type='result' > > from='pubsub.shakespeare.lit' > > to='franci...@denmark.lit/barracks' > > id='sub1'> > > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <subscription > > node='princely_musings' > > jid='franci...@denmark.lit' > > subscription='subscribed'/> > > </pubsub> > > </iq> > > > > In this point the entity does not yet know if it is a publisher, a > > member, (or something else) in the node so it needs to retrieve it's > > affiliation list > > (http://xmpp.org/extensions/xep-0060.html#owner-affiliations-retrieve). > > Same situation will happens with "Subscription Requests" with possible > > Subscription approval notification. > > Typo here, i meant to use ofcourse > http://xmpp.org/extensions/xep-0060.html#entity-affiliations, not the > owner one. > > > 2009/12/19 Tuomas Koski <koski.tuo...@gmail.com>: > > Would it be completely silly idea to add the current affiliation state > > of an entity to the success/event replies of above examples? Also what > > is the reason to support "Retrieve Subscriptions" and "Retrieve > > Affiliations" in separate stanzas? Both must exists for an entity, > > right? Would the workflow be more simply by adding the affiliation > > state information to the "Retrieve Subscriptions" result set? > > > > For example, Entity requests all current subscriptions > > > > <iq type='get' > > from='franci...@denmark.lit/barracks' > > to='pubsub.shakespeare.lit' > > id='subscriptions1'> > > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <subscriptions/> > > </pubsub> > > </iq> > > > > > > Service returns all current subscriptions with affiliation state: > > > > <iq type='result' > > from='pubsub.shakespeare.lit' > > to='franci...@denmark.lit' > > id='subscriptions1'> > > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <subscriptions> > > <subscription node='node1' > > jid='franci...@denmark.lit' > > subscription='subscribed' > > affiliation='publisher' /> > > </subscriptions> > > </pubsub> > > </iq> > > Or should the entity just request subscriptions/affiliations in a follow > way: > > <iq type='get' > from='franci...@denmark.lit/barracks' > to='pubsub.shakespeare.lit' > id='subscriptions1'> > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > <subscriptions/> > <affiliations/> > </pubsub> > </iq> > > And expect a reply to something similar as: > > <iq type='result' > from='pubsub.shakespeare.lit' > to='franci...@denmark.lit' > id='subscriptions1'> > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > <subscriptions> > <subscription node='node1' > jid='franci...@denmark.lit' > subscription='subscribed' /> > </subscriptions> > <affiliations> > <affiliation node='node1' > jid='franci...@denmark.lit' > affiliation='publisher' /> > </affiliations> > </pubsub> > </iq> > > > Calling for thoughts from wiser men :-) > > Br, > -- > Tuomas > xmpp:tuo...@xmpp.lobstermonster.org<xmpp%3atuo...@xmpp.lobstermonster.org> > Hi Tuomas, I do prefer the latter one " <iq type='get' from='franci...@denmark.lit/barracks' to='pubsub.shakespeare.lit' id='subscriptions1'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <subscriptions/> <affiliations/> </pubsub> </iq> " But only in case that the subscription and affiliation states are ket live, and if any changes on those the cahnegs will be published to the entity, propably with option to publush or not to in the request. By my opinion other possibility is to have similar "live" affilation state per subscribtion id where one will receive it's affiliation state for certain node/subscription just by listening those messages. br, Ville
