Salut,
gustav trede wrote:
>
>
> 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.
OK
>
>
>
>
> 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 )
Yes, we must be careful with API change as all existing application
might breaks.
>
> 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 =)
LOL! I've got your code change, will take a look now. Thanks!!
-- Jeanfrancois
>
> regards
> gustav trede
>
>
>