I've thought about this from time to time. I remember using tinyfugue way back when, back in the days of my 1200bps modem.

I'd be interested in trying out whatever you come up with. One thing you might consider building in from the start is a pluggable board interface, so with some future work you could make everything but the board be retro, but still be able to easy-click the moves and have something nicer to look at while playing.

One aspect of the telnet experience that is lost completely when moving toward a gui, is the strict sense of all events flowing along the same time scale, e.g. when someone makes a move, logs in or out, shouts etc... Its' a disadvantage to have everything mangled together, but there is something nice about it too.

Would you use CLIP?

CLIP is excellent for ease but is a bit noisy.  I wish it'd been around when I programmed my GUI.  Burper's mention of sequential text processing is interesting.  It does add a flavor to FIBS.  In my GUI, for which I would have to dig thru stacks of paper for source code, there is no limit to windows, and comments whether shouts, kibitz, message or tell can be piped into any and all windoze selectively.  (The method of doing so is a bit cludgy)

One facet of telnet I've never seen handled is the packet out of order error.  It results in many disconnects.  The solution is to key your program to wait for any expected response from FIBS before it sends any new messages.  For example:  A shout needs a "you shout" response.  When you see a FIBS-quake, this is usually what is occuring, and most of the GUIs get booted, when the fastest reconnect is simply to fail to be disconnected by the error.

--
don
 

yes

I miss my 1963 Pontiac Catalina. Is there anything you can do about that ?

NIHI

I've tried 2 graphical clients, and I found them far too confusing. I currently play over telnet, but anything with ncurses/readline support would be great.

I could help out with the programming, but looking at the screenshot I would say you're doing fine on your own.

The only protocol related problem I'm aware of is the "run-on" message problem that is discussed in the CLIP documentation. I've never seen a packet out of order issue, and if there is one, it certainly isn't a TCP stack problem, but it could be a threading issue in the FIBS server software. But again, I have never heard of such a problem.

It may be that a client sends a flurry of messages together, and I seem to recall that it is possible to overload the server's message processor so that some of the messages are discarded. In general, it is better to throttle packet sending somewhat to avoid that problem.

Of course, if we had access to the server code, or there was someone who cared about it, we could know exactly what goes on in the server.

CLIP offers other advantages over the non-CLIP protocol, mostly around better information about logged in users, and there is little reason to not use it. However, if the intent of this retro client is to just display messages, the formatting of the non-CLIP protocol is more human-friendly.

Thanks, I hadn't considered that, but it might be the easiest way to go.