[standards-jig] WebPresence

Michael Brown michael at aurora.gen.nz
Fri Nov 1 15:19:13 UTC 2002


>> There is a reason for this (I think).  I want it to be extremely
>> easy for people building entry-level webpages to take advantage
>> of this standard. The whole idea is to make this (at least in its
>> simplest format) as easy as including a graphic on your webpage.
>> Many people don't have access/skills/interest to run PHP or
>> Perl to do one simple task, so this is better to be done on the
>> server.  If I want add a presence indicator to my email sig,
>>how do I do that that with PHP or Perl?
>>
>> Let's take a leaf out of ICQ's book here - check the link in the
>> JEP to see how easy it is for people to include the ICQ
>> indicators on their webpage/email sig etc.
>>
>> Of course I am quite happy if you want to extend this to
>> also provide a more comprehensive database that can be
>> queried via scripts..
>
> Well if we are going to take a leaf out of ICQ's book then we will be
doing
> exactly what I said, the end user that is putting the presence in their
> email sig or site does not need to know PHP or Perl, I think you
> mis-understood what I said, its only the provider of the indicator service
> that needs to know the PHP or Perl, and they would be the only people that
> are going to have access to the database anyway.

I think I see what you are getting at.  And yes I did misunderstand.  Just
to clarify - I don't care what this agent is written in - Perl, PHP, Visual
Basic, it's all the same to me.

> ICQ works by having scripts on their webservers that deliver back the
> presence of a user (IIS servers I believe) using ISAPI scripts, you are
> suggesting that a web serving component should be part of the component,
but
> IMO it definately should not be, all that needs to be provided is a jabber
> module that collects the presences and puts it into a database,

Almost true.  You also need the ability for the user to have some control
over what information is being published.  In the proposed case, this comes
from an agent that the user can manually log onto or off.

> then you
> provide various scripts in all the different web scripting languages
> people are likely to use which the provider then just installs onto
> their webserver, there is no point writing a cut down webserver
> when a simple web script will do, it also allows people to utilise
> their web existing serving technology, and customise it if they so
> desire.

I'm all for customising, but what I want to define here, is a base set of
behaviors that will be common across all such scripts, so that third party
websites can blindly assume that each script will send them the same result.

>>> It doesnt have to run on the jabber server itself so this will most
>>> likely not really be a problem, and in practice I expect people
>>> would add it to their existing web server anyway, not their
>>> jabber server.
>>
>> Sure.  Provided the domain is the same as the one in the JID this works.
>
> Now this opens another kettle of fish, the presence indicator shouldnt
have
> to be on the same domain as the JID, in a lot of cases it just isnt
> feasable. A much better option (assuming a users presence service is on
> their own provider) would be _opi.domain rather than domain, as someone
may
> well have to setup all sorts of firewall port forwards to get it to the
> right server when this is supposed to be simple.

Can you explain what you mean by an _opi.domain?

>> There is a problem with this.  If I assume that the Jabber server is also
>> the "WebPresence server", then in order to get the presence, I only have
>> to know the users JID.  If I have to access a third party server in order
>> to get this information, then I need to put a process in place to
determine
>> that servers details - that gets complicated fast...
>
> IMO its a terrible idea to restrict people to using a webpresence service
> based at their jabber provider, it may seem to make things simpler but it
> restricts things far too much, what exactly is the reasoning for this?

It makes things simpler :-)  I agree, it is a dilemma.

> Would someone displaying someones web presence really
> just need their JID to find out their presence server, or would
> the person actually using the webpresence (the end user)
> already know it.

You or I would know what our webpresence server is - sure.  I think you are
vastly overestimating how much attention a non-technical users is going to
pay to something like this though.  I know people that find it a struggle to
remember their email addresses.

> If the reason is that for things like community collaberation sites
> (e.g. slashdot) when displaying someones presence for it to work
> it must be at the same domain then I just think thats being lazy,
> its not hard to just ask someone what the URL of their web
> presence server is

You are underestimating laziness.  90% of people aren't even going to
remember another server name, let alone take the time to type it in.
Remember the parallels to the ICQ system here.  For that the user only has
to enter their UID - (it is way easier for them of course, because they only
have one server domain)

> or when adding have the script discover that itself by
> querying their jabber server and then store the URL.

This is better.  I think I would be happy if there was a way to query the
Jabber server for this information.  This is going to require something like
disco or pubsub that doesn't seem to exist yet however.

>> I think I have looked at it in the past, but it was a web-side
>> script rather than a Jabber server script like I am advocating here.
>
> Its not simply a web-side script, its is a combination of two things, very
> similar to the system you are proposing here, except it is logically
broken
> in two where you are providing services to each system, there is a
component
> in the server handling the instant messaging interaction storing the
> presences to a database and there are web scripts that can then read that
> database and quickly display that information to web browsers, its just
not
> all built into a single component which IMO is not the best way.
> Its best to optimise each different kind of service you are providing
using
> the correct tools and methods, not to make a all encompasing component
that
> does far more than it needs to do, it duplicates existing work (apache)
> wasting time, and possibly introduces security problems.

As I've said above, I'm all for the webserver component being on another
physical box, but there needs to be some way of resolving the issues
associated with it being on a different domain.

Also, I'm not sure if it is that big an ask.  People seem happy with scripts
on webservers connecting to Jabber servers etc.  I can't see a huge problem
with a agent on the Jabber server serving up some HTML from time to time.
Of course the more flexible we can make it the better.

Michael.




More information about the Standards mailing list