I would appreciate anyone writing their own chatterbox clients to use the URL's listed in my previous post to get the necessary information. That should lighten our load a bit and hopefully make some of those ugly errors disappear until we get a dedicated server. Also I'd appreciate it if anyone who writes such a client would let me know so I can offer a link to their client on this site and can notify them if I decide to change the suggested update intervals or the locations of XML for them to grab.

vroom | Tim Vroom | vroom@cs.hope.edu

Replies are listed 'Best First'.
(jcwren) RE: Your chatterbox clients
by jcwren (Prior) on Jun 11, 2000 at 08:10 UTC
    I was playing around with the XML schtuff, and noticed that for both the chatterbox XML node and the user XML node, that they are both bracketted by <CHATTER>.

    I'm wondering if for future compatibility where both may be delivered at once, if the user XML should be <USER> instead.

    In addition, should the 'author' tag be changed to match the 'username' tag so that information such as the node_id can be cross-correlated?

    --Chris
Make our lives easier!
by Anonymous Monk on Jun 02, 2000 at 18:17 UTC
    I've come up with some difficult (not impossible) problems imposed by the current setup: Retrieving private messages requires passing a cookie with user info. Tough, but not impossible. How 'bout adding more options to the cgi to allow us to authenticate that way?

    =Brian

(jcwren) RE: Your chatterbox clients
by jcwren (Prior) on Jun 10, 2000 at 05:41 UTC
    Would it be practical to have a 'system' XML node that would indicate such things as the XML link locations, update times, and any other pertinent information that might change?

    --Chris
RE: Your chatterbox clients
by BigJoe (Curate) on Jun 02, 2000 at 04:40 UTC
    This is just a suggestion, but the clients might be less costly on the server if the script to post actually would open a socket to the clients and dump the message to them right after it gets posted. I am not sure on how expensive sockets would be on the server though.

    Joe

    Maybe this can spark some Ideas!!
      I think that having the server to open a socket to the client is not a good idea: how would you manage clients that are behind a proxy or a firewall?
      marcos