richard at dobson-i.net
Fri Nov 1 14:36:32 UTC 2002
> > Hi, these are my observations about the JEP
> Thanks for the feedback... Replies inline.
> > > 3.2 Web Side
> > Why restrict it to just PNG images?, some users will not be able to view
> > not everybody will be running the latest web browsers, most might but
> > all.
> I'm fairly agnostic when it comes to images formats. I chose PNG for the
> example since it doesn't have the patent/IP baggage that GIF does. JPEG
> would be an alternative I guess....if you don't mind doing JPEG
> on 16x16 images.
> > > 3.3 Server Side
> > > As part of a Jabber server install, the WebPresence agent should be
> > installed and configured. The webserver component of the agent
> > > listens on port 80 of the server machine. Each time the cgi script is
> > called, the script checks to see if the specified user has subscribed
> > > to the WebPresence agent, and returns the appropriate response.
> > The presence component doesnt have to serve the web requests itself and
> > it shouldnt, all the jabber webpresence component should do is process
> > interaction with the jabber system and save the presences into a
> > which can then be read by a PHP, Perl, or whatever script people want to
> > use, this allows much more personalisation for the provider, and will
> > existing technology properly, why do we have to write a webserver into
> > component, whats the point when we already have apache.
> 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
> 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
> 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
> 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
> 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.
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, 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.
> > > 6.5 Server Load
> > > Although no where near as much as a regular webserver, an additional
> > (bandwidth, CPU, TCP connections) will be placed on
> > > the Jabber server, as it has to supply images and text output for
> > as they are loaded.
> > It doesnt have to run on the jabber server itself so this will most
> > 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.
> > > 6.6 Server Dependency
> > > In cases where Jabber server admins are unwilling or unable to run a
> > WebPresence agent, it means that there is no way that the users
> > > can make presence information available on the web. It also means that
> > webpages that are written with the assumption that all servers
> > > provide a WebPresence agent will display missing file icons in place
> > the Jabber status icons.
> > This doesnt make sense to me, since using the presence subscription
> > indicate you wish to subscribe to the presence indicator means you can
> > subscribe to an indicator on a completely different server, so infact
> > is no requirement to run a presence indicator service yourself, you
> > even refer to someone elses in your agents list (after getting
> > from the provider of course :) ).
> 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
> 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? 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. 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 or when adding have the script discover that itself by
querying their jabber server and then store the URL.
> > Richard
> > P.S. I already have a component that performs this functionality in a
> > similar way which displays my basic presence on my website.
> > Although it is not available at the moment pending an Apache and PHP
> > of my server tonight.
> I think I have looked at it in the past, but it was a web-side script
> 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.
More information about the Standards