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 < [EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 9:37 PM, Gerolf Seitz <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
