[vysper] binding multiple resources per session

[Gerolf Seitz]

hi,

as stated in rfc3921bis-04 [0] 8(8.5.1, 8.5.4), a server MAY support binding
multiple resources
per session.if it does, it MUST support unbinding of resources via a client
request.
also, every stanza from the client MUST have a from attribute with a full
JID.

now the question arises, whether we want to skip the implementation of
multiple resources per stream for now, as it seems to make things more
complicated
than they have to be in these early stages.

i'd rather see the support for most usecases sooner than fiddling with this
extra stuff.

wdyt?

  Gerolf

[0]
http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#bind-multi

[Bernd Fondermann-2]

On Mon, Apr 21, 2008 at 9:37 PM, Gerolf Seitz <gerolf.seitz@...> wrote:

> hi,
>
>  as stated in rfc3921bis-04 [0] 8(8.5.1, 8.5.4), a server MAY support binding
>  multiple resources
>  per session.if it does, it MUST support unbinding of resources via a client
>  request.
>  also, every stanza from the client MUST have a from attribute with a full
>  JID.
>
>  now the question arises, whether we want to skip the implementation of
>  multiple resources per stream for now, as it seems to make things more
>  complicated
>  than they have to be in these early stages.
>
>  i'd rather see the support for most usecases sooner than fiddling with this
>  extra stuff.
>
>  wdyt?
>
>   Gerolf
>
>  [0]
>  http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#bind-multi

we are not so far from finding an acceptable solution I think.
recording the resoure id(s) in the session is simple and effective.
see my comments in the related thread.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Gerolf Seitz]

i dug more into the presence and roster management and it
seems like we should introduce an abstraction for a resource.
mostly because a resource can be in a certain state:

connected: after binding to session
available: a connected resource that has sent initial presence information
"interested": an available resource that has requested the roster


there are some implications when an available resource does not request it's
roster
(eg. a mobile client).
see
http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#roster-login

for simplicity and ease of use we could do
enum ResourceState { unbound, connected, available, interested };

interface Resource extends Entity {
  public boolean isConnected() { ...};
  public boolean isAvailable() {...};
  public boolean isInterested() {...};
...
}
and implement this as ResourceImpl, which should be added to the
ResourceRegistry.
but then again, we might aswell add those methods to Entity directly.

the SessionContext could proxy a call to the resource registry with
List<Resource> getBoundResources().

does that make any sense?

  Gerolf

On Mon, Apr 21, 2008 at 10:06 PM, Bernd Fondermann <
bernd.fondermann@...> wrote:

> On Mon, Apr 21, 2008 at 9:37 PM, Gerolf Seitz <gerolf.seitz@...>
> wrote:
> > hi,
> >
> >  as stated in rfc3921bis-04 [0] 8(8.5.1, 8.5.4), a server MAY support
> binding
> >  multiple resources
> >  per session.if it does, it MUST support unbinding of resources via a
> client
> >  request.
> >  also, every stanza from the client MUST have a from attribute with a
> full
> >  JID.
> >
> >  now the question arises, whether we want to skip the implementation of
> >  multiple resources per stream for now, as it seems to make things more
> >  complicated
> >  than they have to be in these early stages.
> >
> >  i'd rather see the support for most usecases sooner than fiddling with
> this
> >  extra stuff.
> >
> >  wdyt?
> >
> >   Gerolf
> >
> >  [0]
> >
> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#bind-multi
>
> we are not so far from finding an acceptable solution I think.
> recording the resoure id(s) in the session is simple and effective.
> see my comments in the related thread.
>
>  Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>

[Gerolf Seitz]

On Mon, Apr 21, 2008 at 11:16 PM, Gerolf Seitz <gerolf.seitz@...>
wrote:

> interface Resource extends Entity {
>   public boolean isConnected() { ...};
>   public boolean isAvailable() {...};
>   public boolean isInterested() {...};
> ...
> }
>

actually, i think this is not a good idea.
it doesn't fit how we use Entity now.
this information should rather be held in sessioncontext or resourceregistry
alongside maybe with convenience methods like
Iterator<Entity> getInterestedResourceIterator();

  Gerolf

[Bernd Fondermann-2]

On Tue, Apr 22, 2008 at 7:41 AM, Gerolf Seitz <gerolf.seitz@...> wrote:

> On Mon, Apr 21, 2008 at 11:16 PM, Gerolf Seitz <gerolf.seitz@...>
>  wrote:
>
>
>  > interface Resource extends Entity {
>  >   public boolean isConnected() { ...};
>  >   public boolean isAvailable() {...};
>  >   public boolean isInterested() {...};
>  > ...
>  > }
>  >
>
>  actually, i think this is not a good idea.
>  it doesn't fit how we use Entity now.
>  this information should rather be held in sessioncontext or resourceregistry
>  alongside maybe with convenience methods like
>  Iterator<Entity> getInterestedResourceIterator();

ok, sounds reasonable.

   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...