Yes this would help some but not all people. e.g. If I where at the public library and for some reason wanted to use jabber to talk to somebody. The library around here do not have Java installed and I'm not in a position to go and install a client on there machines.
OR I cam sitting in my VB programming class(***SHUDDER*** at least it is a easy A) and he starts lecturing on loops or some other equally useless topic that anyone should be able to get out of a book. I could go online and chat once again I don't have the permissions to install the client and there is no Java installed. While the need for a pure HTML client is potentially small it does fill a niche market. Although I admit any implementation will very likely be hard on the server. Esp for a more that trivial number of users. ~Chris On Fri, 2003-01-03 at 14:44, Dave Meador wrote: > A pure http chat interface would be great, but is also a very difficult > problem. Given that you *can* manage state by creating a session in PHP or > something similar, but the problem is notifying the client (browser in this > case) when a chat message arrives for the client and needs to be displayed. > To my knowledge, the only way to do this is to have a refresh-button that > will trigger an update to redisplay the page with the new information. That > is ugly! Or you might use a polling like mechanism where you constantly > redirect the web page for updates, which is even more kludgy and slow. > > How were you planning on solving the client-notification problem? I think > there needs to be a client-side process running that maintains a connection > to the sever... thus Java and Flash based solutions. > > The need for a chat client on the HTTP port stems from the following issue: > Most companies block chat ports either deliberately or inadvertantly > depending on their IT policies. Also, most companies have the HTTP port > open for whatever reason. Since this port is more often than not open, it > is easier to utilize the already open port for a service rather than annoy > the IT guys to open the proper port usually to no avail. So why not provide > a chat server that listens on port 80 and setup the client to connect to > chat.domain.tld:80 and to all your... and of course the nice thing about > having a Java client (or Flash or whatever) is that you can use it > (supposedly) on any browser that supports Java eliminating the need for a > chat client to be installed on the client machine. Of course thats just my > opinion. </rant> > > --Dave > > ----- Original Message ----- > From: "Mike Shoyher" <[EMAIL PROTECTED]> > To: "Richard Dobson" <[EMAIL PROTECTED]> > Sent: Friday, January 03, 2003 8:20 AM > Subject: Re[2]: [JDEV] webclient project > > > > Hello Richard, > > > > Friday, January 03, 2003, 6:51:00 PM, you wrote: > > > > RD> Its probably better to help the existing projects rather than create a > whole > > RD> new one of your own, I think i saw a javascript one a while back that > looked > > RD> promising. > > > > All the clients I found so far aren't pure web, they use either flash or > > java to connect to the server. I had an intention to make a > > jabber-based web chat, but things look quite complicated to me. > > > > The major problem is our beloved statelessness of the HTTP. That means > > the web server must keep all sessions to the jabber server. I don't > > see a good way to do it using mod_perl. > > > > Probably it would make sense to invent special stateless transport for > > the jabber server. The jabber server keeps sessions anyway so we could > > unburden the client and provide a way for the client to send what it > > wants and fetch the whole backlog of waiting messages. > > > > -- > > Best regards, > > Mike mailto:[EMAIL PROTECTED] > > > > > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > >
signature.asc
Description: This is a digitally signed message part
