in reply to Re^4: A new chatterbox flavour
in thread A new chatterbox flavour

Well, what is the purpose?

If you take a look to Other Users, at any point in time there will be at least a few people that show up, but who aren't actually present, they just left Fullpage Chat or some other chatterbox client open. Such an automatic check of messages, either personal or chatter, should not register as presence, IMHO.

I don't plan on adding even more cruft to better support a scenario that's only temporary…

I can have no argument whatsoever with that.

It is not fair that a shortcoming in the site should be patched in a chat client, in every chat client. It is the responsibility of the site to treat these things properly, whatever anybody deems proper.

IIRC cookie processing, and thus marking the presence of a user, happens at a very early stage, before any custom node code can have a say in it. That way, a patch would have to dig very deeply into the guts of the site. I have serious doubts whether the people responsible for the state of the site would be so happy to have that happen.

Replies are listed 'Best First'.
Re^6: A new chatterbox flavour (presence)
by tye (Sage) on Jan 14, 2005 at 18:16 UTC

    Chatter clients have a chance of making a reasonable determination as to whether someone is present. A good client allows the user to say whether they want the client to make them appear logged in or not and, if it is making their presence known, then it should provide a time-out after which no interaction means that it automatically stops making their presence known.

    Perhaps you are thinking that PerlMonks should not count chatter fetches as "presence". We do better than that, we let you pick. I could support making chatter fetches not count as "presence" by default, but then we'd need a way to specify two types of non-default behavior, which will make ;ticker= confusing and introduce a backward compatability problem.

    Or we could take away the option to have chatter fetches count as presence, which means that several clients will require enhancements in order to provide features that they already provide and that people want (and will add to site load required to provide that feature).

    It isn't hard to "fix" presence processing such that it happens elsewhere and can be overridden many places.

    I don't see how to make PerlMonks do a good job of detecting presence. Clients can do a good job of this but most client authors don't bother to and, yes, doing that right varies by client.

    - tye        

[reply]

      Thanks for the elaboration. You have put an item on my todo list for the client which in retrospect seems obvious.

      Makeshifts last the longest.

[reply]
Re^6: A new chatterbox flavour
by Aristotle (Chancellor) on Jan 28, 2005 at 23:43 UTC

    I am late, but I didn't want to leave this unanswered:

    It is not fair that a shortcoming in the site should be patched in a chat client

    I'm not sure entirely what this is referring to, but what I meant to say in my post is that a separate login on this client is only required because browsers do not send cookies to sites other than the originating one nor do they allow Javascript to read cookies for sites other than that which the Javascript code originated from. This is for security reasons.

    If the client was hosted on PM, and it's supposed to be one day, then the Javascript will have access to the cookie you already have, and will not require logging in separately.

    Makeshifts last the longest.

[reply]

In Section Perl Monks Discussion