|
»
»
« Return to Thread: [vysper] binding multiple resources per session
Re: [vysper] binding multiple resources per session
by Gerolf Seitz
::
Rate this Message:
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@...
>
>
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@...
>
>
« Return to Thread: [vysper] binding multiple resources per session
| Free Forum Powered by Nabble | Forum Help |
