>
> It can be used to check for logedin client for example.
> now i must use en extra external hasmap just for this.
>
You can always call CometContext.isActive(CometHandler) to detect that
scenario.
well that requires external extra synchronization.
that is redundant, and lowers concurrency without good reason,
cause needed logic is allready done inside the
CometContext.addCometHandler(CometHandler handler) ,
problem is that the outcome of what happens inside that method is keept
secret.
> gustav trede wrote:
>
>>
>> int CometContext.addCometHandler(CometHandler handler) returns the
>> comethandlers hashcode, how come ?
>>
>
> yes that was a decision I took almost 3 years ago. At that time I was
> returning the hashCode but I was planning to return a unique identifier. The
> idea here is to avoid having to keep a reference to your CometHandler, but
> use this unique id. Later you can always re-use that ID to notify directly a
> single client and not the entire group.
>
>
>
>> the hashcode is known by the calling context.
>> its redundant information.
>>
>
> But how can you get that information from your Servlet?
the servlet that created the comethandler can do the .hashcode() call
itself ,
Or if the hashcode simple is representing a know value like userid, that is
known too.
hence the value of CometContext.addCometHandler return is very redundant.
im using a unique userID int as hashcode for comethandler.
so whenever i want to send message to a user i simple get the userid for
the target user from database or other place.
This way i dont need to do any extra layer of maping between comethandlers
hashcode/ID and the user it represents.
you want to keep the int CometContext.addCometHandler(CometHandler handler)
as is right ?.
thats fine, then i will simple code around it, so i can know if that
comethandler(hashcode) exists or not before adding it to the cometcontext.
its checking for if the user is allready logedin or not.
but that requires extra external list of loged in users /.
problem is the doc now states its the hashcode that is returned, and people
might depends on that like i do now.
so if you start to generate unique values and return them it will break the
current API contract.
and if keeping the current implementation, it returns meaningsless
information.(the caller can do a hashcode() call itself )
enforcing generation of unique maping IDs is something that is nice only if
its overridable,
so that usage cases that allready have unique ids for their comethandlers
can use them in a cometcontext subclass .
The current api for notify in cometcontext is fine, at least in my opinion.
its interesting how simple things like this, can get complicated =)
regards
gustav trede