On 29.09.11 22:50, Mike Mahoney wrote:
>
> On Sep 28, 2011, at 5:43 AM, Niklas Gustavsson wrote:
>
>> On Wed, Sep 28, 2011 at 10:43 AM, Bernd Fondermann
>> <[email protected]> wrote:
>>> It was proposed to remove support from binding more than one resource
>>> per session. Having mutliple resources per session is a corner use case.
>>> Probably nobody is using it and even fewer understand how it could
>>> possibly work.
>
> It looks like people were in favor of this, so I've begun working on it.
>
> Looking over the DefaultResourceRegistry it looks like there are some
> improvements that can be made if this isn't supported. One thing I am
> considering is making a change to AbstractSessionContext.bindResource().
> Once the resource is bound, the resource field of the context's
> initiatingEntity could be set. That could remove the need for methods such
> as ResourceRegistry.getResourcesForSession() and
> ResourceRegistry.getUniqueResourceSession(), since the resource could just be
> queried from the SessionContext. Would people be opposed to removing those
> methods and refactoring the code that calls them? I'm still pretty new to
> the Vysper source, so just let me know if I'm missing something or if this is
> a bad idea.
You're right. ResourceRegistry would be greatly simplified.
Let's see:
a.
a1.
Map<SessionContext, List<String>> sessionResources
=> Map<SessionContext, String> sessionResources
a2.
Move resource id into SessionContext (could be done in a second
refactoring step)
b. SessionData
resourceState and priority can be conflated into SessionContext
NOTE: priority must be kept!
AFAICS, we would need to retain the other datastructures.
Please, let's separate the issue of having arbitrary resources accepted
from the client (VYSPER-297) from the issue of removing multiple
resources per session. For the latter, I've opened VYSPER-298.
Mike, I'm very much looking forward to your patches. It'd great if you'd
keep them small and keep the unit tests in mind. Thank you!
Bernd
