At 05:25 PM 8/2/2002 +0200, JFC (Jefsey) Morfin writeth:
>I like the idea. I am not good enough to respond on the public list. Might
I highly doubt this list does not welcome new people to the list. Being
"good enough" is just in your own imaginative mind. As far as I know,
people are allowed to express their own opinions on new protocols on this
list (that's what it is here for). Personally, I welcome any new ideas and
suggestions on this particular draft.
>I suggest that a good thing would be to try to test the concept with a few
>simple applications? They would then serve as examples for developpers. I
>am considering ways to address the following two problems which might be
>generic needs (support under MS, MAC and Linux) and the occasion to include
>librairies for theses platforms?
Shining Light Productions is thinking of providing full ANSI-C source for
the functions listed in the implementation section. This would allow
developers to cut-and-paste the code into their applications...allowing for
ultra-fast development. Also, sample server and client code would be
added. However, the Company still has yet to decide if releasing portions
of LibLink will occur since much time was spent crafting the socket section.
This concept is already implemented in the commercial ProtoNova Web Server.
If people just want to check it out to see that it really works, they can
download and install the software.
The protocol is generic enough that it will probably work on any network
stack. So, Windows, Linux, Macintosh, OpenBSD, and anything with
networking support will work fine with the Unified RFC Protocol.
>1. to have a direct interface to a web service on my screen. Able to be
>interactive and to support file transfer (printing, filing). I suppose this
>is something you know doing may be off the shelves?
I'm not exactly sure what you are wanting to do here. Perhaps you can
clarify what you mean by being "interactive." The Unified RFC Protocol is
designed to be readable by Telnet clients (up to the point of RAW data).
The Unified RFC Protocol is optimal for data transfers like those found in
FTP...however, the protocol I've defined is far more versatile and robust
than FTP.
>2. to resolve the DNS on a remote server in the background (intercept the
>request, resolve and enter the IPs) without having to change the used PC,
>MAC, Linux station parameters (this is to study a secure DNS resolution
>scheme): a plug-in + relation with the server.
Again, I'm not quite sure what exactly you want to do with the protocol
here and clarification is needed.
>A question: the protocol is quite readable. But is there no room for saving
>space in the header?
The header is not likely to change because it guarantees that the protocol
is still functional and the server/client hasn't gone haywire. Granted it
consumes quite a bit of space, but if space is an issue (e.g. via UDP), a
positive response packet can be reduced to a minimum of 39-50 bytes.
Hope this helps!
Thomas J. Hruska -- shinelight@shininglightpro.com
Shining Light Productions -- "Meeting the needs of fellow programmers"
http://www.shininglightpro.com/