[JDEV] RE: [Win32-dev] Interface Ad Ins?

[Thomas Charron]

Quoting Keith Minkler <keith at digix.net>:
> A jabber Client is supposed to 'inhereit' its functionality from the
> server... all the transports, etc. reside on the server, and the jabber
> client need only know how to send messages to the server.  how it displays
> the messages is entirely up to the server, but there are some guidlines...
> messages of type 'normal' are supposed to be displayed in a ICQ-style
> message dialog, type 'chat' are displayed in a AIM-style chat window, and
> 'groupchat' in an IRC style window..., of course, the client developer
> doesn't have to follow these guidelines at all, and may display the message
> however it wants..

  Yes, and no.  Messages coming thru should always have a displayable subject 
and body 'text', but some transports and clients may wish to 'extend' the data 
by using additional xmlns tags within a given message, that ordinary clients 
would in turn ignore.  See my previouse example.  I may wish to have a docked 
stock ticker that simply lists my stocks.  Doing this via solid IM would be a 
pain in the arse.  Do I really want a window popping up every few minutes to 
see my stock prices?  Heck no..  But I may want to client to silently update a 
rolling ticker that I can glance at on occasion.

> A client is supposed to be as dumb as possible, this allows for the client
> to get out into the field, and still be usefull many months (and new
> transports) later, without the need for an update... certain things like
> stock tickers, will have to be handled "special" by the client, and for
> those sorts of things, your right, a simple plug-in type client would
> certaintly go a long way.. :)

  Hrm.  Perhaps we are going on the same thought process then.  The basic 
answer is, though, that transports can support both.  So long as we've got 
plain old text to display, they can hijack whatever other data they want to.

  <These messages are forwarded to jdev as well, as I think it deals more with 
general client design concerns, and less specific Win32 functionality.  I won't 
forward messages that are Win32 specific, but other OS client developers may 
want in on this particular conversaiton>
--- 
Thomas Charron
<< Wanted: One decent sig >>
<< Preferably litle used  >>
<< and stored in garage.  ?>>