[JDEV] Large rosters + a solution for the commands syntax problem

Michael Hearn mhearn at subdimension.com
Sat May 26 11:03:01 CDT 2001


Hi, I get the digest here so sorry for the lack of quotes/threading etc.
BTW, what happened to NNTP access to this list?

Anyway, two things.

1) Large rosters. I don't see the problem here - why oh why does the server
have to parse the rosters of all the people that presence is being SENT to?
That's the impression I've got, maybe I'm wrong, but surely to change
presence all the server has to do is load and parse that bots roster then
generate a <presence> packet for each one which gets sent to the client if
they are online or not, or to another server. There should be only 1 roster
parse, or am I wrong? Anyway, I agree with Jens that this seems to be a
major problem - client or transport the server should be able to happily
deal with large scale presence notifications.

2) Command syntax: Yeah, well I see this could be a problem. We can either
continue using natural language for this, which is improving all the time
but does have problems (as in: it can be difficult to know exactly what or
how you can do with the commands/varied syntax) or we can use some kind of
controlled input system like HTML forms only different. Here's my suggestion
(I'll prototype it when I can):

Bots advertise themselves as supporting the commands syntax somehow (in
presence?) and when a client that supports it beings "chatting" to this bot,
what actually happens is that a special message is sent to the bot
requesting the data (or it could be an IQ get/set system). This returns some
XML representing the commands that can be used, which are displayed to the
user as a series of linked phrases, like this:

(i'll use the freshmeat news example here)

* Start chat
* A window appears that looks like this, here [] means blue underlined text
like hyperlinks

[select option]

* The user clicks on the [select option] link and a menu appears with the
Watch and Ignore commands, and maybe others like About etc.
* The user chooses Watch
* The window changes to read

>From now on, send me updates on the (edit) news source.
[ and ]

* The (edit) is just a text edit so we can type in the words we want. The
 and ] link gives us more options, like "and, send me a daily digest", "and,
send me XHTML formatted news items" etc. The user wants both of these
options, so they click the first [and], then choose the option, so it reads

>From now on, send me updates on the (edit) news source,
and send it as a daily digest,
[ and ]


... then ...

>From now on, send me updates on the (edit) news source,
and send it as a daily digest,
and send it as XHTML formatted
[ and ]

Now the user has created a request that identifies their needs to the bot,
so they click OK or whatever and another XML message is sent to the bot with
the data the user entered. The bot returns a text message saying, "Thanks
for using PersonalBuddy, I will:  send you updates on the (edit) news
source, and send it as a daily digest, and send it as XHTML formatted." to
let the user know it went OK. The same interface can be used to unsubscribe
:

[ select option ]   >   Unsubscribe   >    [ select news feed ]    >
Freshmeat.net   >  OK

Anyway, I know this approach has some problems, most notably client support
is required which sort of does away with the whole point of IM bots which is
that they are like other people and all you need is the IM software, but  I
believe it -is- powerful and flexible. Also I suppose that for clients that
didn't support this or didn't want to use it (ie sent the bot a plain text
message) it could go to the natural language interface. Anyway, comments
anyone?

thanks -mike





More information about the JDev mailing list