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

So if you can't read the cookie, perhaps there's a simple way to ask the site who you are? Maybe by parsing the Login Page, it has a fixed format and contains your user name — take the print version, and what you're after is in the first link in the DIV with the id "content".Or maybe there's even a ticker that's even better suited.

I like the idea of combining a cloaked chatterbox while browsing the site logged in normally. If your browsing and the chatterbox are on the same domain, you can't have that. Not like this.

Is there something we're overlooking? Some parameter for the request which would make this single request cloaked, leaving the cookie intact?

Replies are listed 'Best First'.
Re^4: A new chatterbox flavour
by Aristotle (Chancellor) on Jan 14, 2005 at 07:47 UTC

    I like the idea of combining a cloaked chatterbox while browsing the site logged in normally.

    Well, what is the purpose?

    In any case, the login stuff was cruft added for the interim. I don't plan on adding even more cruft to better support a scenario that's only temporary…

    Makeshifts last the longest.

[reply]
      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.

[reply]

        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]

        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