On Sat, Dec 19, 2009 at 11:46 PM, Tuomas Koski <[email protected]>wrote:
> Hi again, > > (i'll continue my monologue here :) ) > > 2009/12/19 Tuomas Koski <[email protected]>: > > 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='[email protected]/barracks' > > to='pubsub.shakespeare.lit' > > id='sub1'> > > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <subscribe > > node='princely_musings' > > jid='[email protected]'/> > > </pubsub> > > </iq> > > > > > > Step 2: Service replies with success > > > > <iq type='result' > > from='pubsub.shakespeare.lit' > > to='[email protected]/barracks' > > id='sub1'> > > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <subscription > > node='princely_musings' > > jid='[email protected]' > > 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 <[email protected]>: > > 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='[email protected]/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='[email protected]' > > id='subscriptions1'> > > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <subscriptions> > > <subscription node='node1' > > jid='[email protected]' > > subscription='subscribed' > > affiliation='publisher' /> > > </subscriptions> > > </pubsub> > > </iq> > > Or should the entity just request subscriptions/affiliations in a follow > way: > > <iq type='get' > from='[email protected]/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='[email protected]' > id='subscriptions1'> > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > <subscriptions> > <subscription node='node1' > jid='[email protected]' > subscription='subscribed' /> > </subscriptions> > <affiliations> > <affiliation node='node1' > jid='[email protected]' > affiliation='publisher' /> > </affiliations> > </pubsub> > </iq> > > > Calling for thoughts from wiser men :-) > > Br, > -- > Tuomas > xmpp:[email protected]<xmpp%[email protected]> > Hi Tuomas, I do prefer the latter one " <iq type='get' from='[email protected]/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
