richard at dobson-i.net
Fri Nov 1 16:02:20 UTC 2002
> > Well if we are going to take a leaf out of ICQ's book then we will be
> > 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
> > that needs to know the PHP or Perl, and they would be the only people
> > 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,
> Basic, it's all the same to me.
He he sure.
> > 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,
> > IMO it definately should not be, all that needs to be provided is a
> > 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
> from an agent that the user can manually log onto or off.
Of course and the way you suggested of using the presence subscribe etc
seems fine for this (until the ever illusive pub-sub comes along).
> > 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
Oh sure of course I didnt mean that people would be entirely changing the
behaviour, but they will want the ability for customisation which using web
scripts for the output makes a reasonabily easy task, the base interface
just needs to be standardised, thats what I see this JEP as being for.
> > Now this opens another kettle of fish, the presence indicator shouldnt
> > 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
> > 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?
Well just taking some tips from SRV records, using something like that to
state you are requesting a particular service, so it can be easily routed to
the correct server potensially. (opi = online presence indicator)
> > IMO its a terrible idea to restrict people to using a webpresence
> > based at their jabber provider, it may seem to make things simpler but
> > 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
> 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
> remember their email addresses.
Oh yes of course, in that case its only going to be the technical people who
maybe using a different webpresence server and they would know it, and my
suggestion out discovery below solves the problem for users who are just
using their standard webpresence server.
> > 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
> disco or pubsub that doesn't seem to exist yet however.
Im not sure if disco or pubsub really solve this problem, maybe what could
be done is use agents/browse/disco to find out the webpresence host, then
use something similar to jabber:iq:gateway to find out the exact url to use,
this seems like a great solution to me.
e.g. the process could be (W = website, J = Jabber server, P = Presence
<iq type="get" to="jabber.org">
<iq type="result" from="jabber.org">
<item xmlns="jabber:iq:browse" category="service" type="jabber"
jid="jabber.org" name="Jabber.org Dev Server">
<item category="service" type="opi" jid="opi.jabber.org"
name="Online Presence Indicator"/>
<iq type="set" to="opi.jabber.org">
<jid>user at jabber.org</jid>
<iq type="result" to="opi.jabber.org">
> 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.
Sure but that doesnt necessarly mean the script has to be hosted on the same
domain as the jabber server, there are ways, it just has to be decided which
is the best and most flexable way.
> Also, I'm not sure if it is that big an ask. People seem happy with
> on webservers connecting to Jabber servers etc. I can't see a huge
> 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.
Hmm, maybe but with larger installations/user bases it could become a
More information about the Standards