[standards-jig] WebPresence (fwd)

Chris Josephes cpj1 at isis.visi.com
Fri Nov 1 17:19:04 UTC 2002


Oops.  Followups were never CCd to the list.

--------------------
Christopher Josephes
cpj1 at visi.com

---------- Forwarded message ----------
Date: Fri, 1 Nov 2002 10:06:24 -0600 (CST)
From: Chris Josephes <cpj1 at isis.visi.com>
To: Richard Dobson <richard at dobson-i.net>
Subject: Re: [standards-jig] WebPresence

On Fri, 1 Nov 2002, Richard Dobson wrote:

> Thats a bad way to do it, you should not be having to connect to the jabber
> server and log on in order to get someones presence for display on the web,
> thats not a very good way to do it at all, the only really feasable way
> (especially if you are displaying multiple peoples presence) is to have a
> jabber component that always runs and collects the presence into a database
> which a web script can then read 100x faster and 100x more efficent, as the
> script when logging on will be constantly broadcasting its online presence
> and then offline presence to you when someone visits the site, also if you
> do any caching it will not be a true representation of your online status,
> the database method overcomes all the stated problems.
>
> Richard

I agree that it's not the best way to do it.  It's stricty a client-side
hack.  It can still be used by users that have a cgi capable webserver,
but are not online with a Jabber server that provides a server bases
presence solution.

The caching was a necessary evil.  The TTL of 30 seconds was considered
reasonably accurate, but it could always be adjusted based on the number
of hits the program would receive and how often the presence data actually
changed.

For a server-side implementation, you'd need the following.

1. The component that reads all presence data.
2. The CGI script that connects to the server component; or would you have
the component itself listen on port 80 and respond to the HTTP request
directly?

Also, why would the component read all the presence data at once?
Wouldn't that lead to the same problems that caching would?

I'd need to do some reading up on component programming in perl, but I
could try to whip up a server component that could handle the same
features as the current program.

The only immediate downside I could see is there there is no mechanism in
place to handle custom presensce icons per user.  Maybe that can be
addressed in the future.







More information about the Standards mailing list