Written by admin
Sunday, 28 May 2006
Please note that this page may not be updated frequently, while the SVN repository will always be updated with the latest changesAdvanced terminal networking blessThis library is being developed for the lack of a valid networking curses on win32 but will be something more, integrating client/server arch and
easy API. The idea is to have support for the terminal types where colorful games/applications can be developed with simple ascii art. And sound also ;)
FAQ
Q.: why don't you use cygwin+ncurses ?
A.: because I do not want cygwin. It is a good platform, I simply want something stand-alone
Q.: why do you use your RWops library instead of other standard... ?
A.: because it creates a total stream abstraction, has no overhead and allows to handle pretty anything with the same function calls (even if there is a different set for the memory buffers here is used for)
Q.: is this a curses conversion?
A.: No. but there is a basic curses support in the form of a wrapper on the TelBless library API.
Q.: can I use TelBless for console applications (no network)?
A.: there will be a wrapper on the standard curses to allow you use them with TelBless API. ncurses is used for *nix and PDcurses for win32/dos.
Q.: does TelBless support all terminals?
A.: No. TelBless will not support the whole mess of terminals (unless somebody tells me a nice easy way to integrate the terminfo db) simply because they are too much old and their support is not worth. TelBless is enough extensible to let you bind it to any terminal type, but this is another topic.
Q.: this library is crap.
A.: probably true. Do not complain and please give me a hand! I'm working alone on it!
How to compile
You need a certain amount of luck in any case ;)
/ root
/legolude common include files
/rwops RWops library, file/memory streams etc.
/telbless TelBless source code
/telbless/docs some documentation used/willing to be used
Features
This list contains both complete (+) and planned (-) features:
not yet writtenTerminals
Compatibility with the following terminals specification (in order of
complexity):
- VT52/VT100
- generic ECMA048
- fashioning AVATAR
The
terminfo database would be a great abstraction, I have chosen to keep the terminal code separated so that a future integration should not be painful.
Basically, we could provide the terminal base interface for each type of terminal or better a parser for the ''terminfo'' itself. Ncurses is too much complex but we can study how it handles the abstraction for our case.
Client/Server arch
select() based non-blocking asynchronous I/O
Note: It was suggested to use
libevent and I guess it will not be much painful to do, but I will keep the simple select() approach for the first versioning. The best for modern win32 platforms would also be the IOCP, but I won't get on it and just hope that libevent will.
The TelBless API purpose is to abstract in the best way the sockets/terminal layers and to provide simple functions as if writing a local console application, respecting linear programmation principles, but because of the asynchronous approach the code must be well organized.
Server context
The server maintenance code is run after an asynchronous event (''select()'') happens and before processing each event. It can manage each client and eventually disconnect them or sending output on their channels.
Client context
Code which consumes the ''translated'' input and produces output (any size)
without accessing other resources rather than memory. It should not be too much time consuming or the server peformance will degrade (e.g. don't put any sleep()-like function or
huge loop in it)
Client code will return when has finished processing the data (but this does
not mean that the data left on the buffer must be trashed).
The client can update its current context providing new callbacks but the automatic management is limited to 2 contexts (current and previous). More contexts can be extended using the client tag but a context stack is out of purpose for the API. (statement subject to changes)
Internals
Events
Server will:
- run maintenance code (this process may generate pending output)
- wait for writeability of the socket
- write the pending data (dynamic buffer)
- wait for incoming data
- receive incoming data
- translate received data applying the custom hook (if any)
- call the client hook to consume data (translated or not); this process will generate pending output
- loop from beginning
The events are driven by the
writeability of the socket.
Memory copies
- copy from the TCP stack buffer to the raw ''data'' buffer (which is not taken global because the application may simply not need the terminal abstraction
- translate from raw ''data'' to valid terminal ''input''
- copy from ''input'' to user-requested buffers
- move data backward upon consumption
This is the most efficient solution, see the source code for more.
Console emulation
When interfacing a terminal a console-style I/O is emulated. The input will rely on the translated buffer and the output will be cached on a local buffer.
A double buffering mechanism is used by default but a complete display redraw can be forced.
Upon availability for write, the output is sent and its internal pointer resetted.
window
TelBless can manage up to 16 context windows. The first context window is always the whole terminal window. Using tb_pushwin/tb_popwin you can enter into a custom sized slice of the base terminal window. Each subsequent call will output in the currently selected window, and even the cursor will be relative to it (but the cursor is stored as absolute internally).
The double buffering works great with windows because only the modified parts of any window in the chain gets updated; actually, a ''window'' is an
abstraction to ease developing.
| Last updated ( Sunday, 28 May 2006 ) |
| |
