Difference between revisions of "Protocols/TOC/1.0"

From NINA Wiki
Jump to navigation Jump to search
Line 19: Line 19:
  
 
-->
 
-->
 +
 +
TOC ('''T'''alk to '''O'''s'''C'''ar) is a protocol, and a server which connects to the AIM service. At its core, the TOC protocol is string-based, and incapsulated in a [[Protocols/OSCAR/FLAP|FLAP]] packet. As the data transmitted is string-based, it is referred to as SFLAP.
 +
 +
Compared to OSCAR, TOC is more simple, however it is not as flexible and doesn't contain all the features of OSCAR. It does, however, contain the essential features to communicate with the AIM service: IMs, Chat rooms, Warnings, and Privacy Management.
 +
 +
 +
== FAQ ==
 +
 +
This FAQ was originally created by AOL, and is written verbatim. The NINA team has added some notes at the bottom of each answer.
 +
 +
=== What does TOC stand for? ===
 +
TOC, pronounced /talk/, currently stands for TOC to OsCar for lack of a better acronym. Really it just has to do with the members of the TicToc project obsession with useless 3 letter meaningless words. Since TOC is just a proxy protocol, it kind of makes sense.
 +
 +
'''Note''': TOC means "Talk to OSCAR", not "TOC to OSCAR".
 +
 +
=== How does the TOC protocol differ from the OSCAR protocol? ===
 +
The TOC and the OSCAR protocol are very different. The TOC protocol is a high level abstraction of the OSCAR protocol. The TOC protocol is entirely string based while the OSCAR protocol is binary based. Since the TOC protocol is entirely string based there are NO network byte ordering problems, while the OSCAR protocol will require careful packaging of data. (This is excluding the 6 byte FLAP transport layer header, used by both TOC and OSCAR, and will require network byte ordering.) Finally, the TOC protocol is currently the only one officially released and documented.
 +
 +
At the protocol level currently there is nothing in TOC that isn't in OSCAR. However there are things in the OSCAR protocol that are not in TOC. For example TOC will probably never support directory look up, password changing, or other non "core" features. Obviously this translates to the TIC/TiK clients vs AIM clients.
 +
 +
Are there benefits to the TOC protocol vs OSCAR protocol? Well not really, except TOC is extremely easy to work with, and it is at least public. Once you create your OSCAR/TOC independent FLAP layer you don't have to worry about network byte ordering with TOC, which makes portability much simpler. String termination can still lead to memory issues, but a good split routine will solve that problem.
 +
 +
'''Note''': Ironically enough, TOC does support directory look up and password changing.
 +
 +
=== What is FLAP? ===
 +
FLAP is a low-level communications protocol that facilitates the development of higher-level, record-oriented, communications layers. It is used on the TCP connection between all clients and servers. TOC adds a few extra requirements to TOC which are documented in the PROTOCOL file.
 +
 +
'''Note''': Check [[Protocols/OSCAR/FLAP|FLAP]] for more thorough information.
 +
 +
=== Where can I get more information on the TOC Protocol? ===
 +
Download TiK and look in the PROTOCOL file included. TiK should always contain the latest PROTOCOL file, since the maintainer of TiK also maintains the PROTOCOL document. Most of the protocol and the ordering of messages is documented in this file. For support send your questions to the tictoc-users mailing list.
 +
 +
=== But strings in C are ...? ===
 +
Many folks think working with strings in C is hard, inefficient, cpu intensive, buggy. While there are some gotchas to worry about, in most cases this is simply not true.
 +
 +
Working with the TOC protocol in C is only slightly harder then in a language that treats strings as first class object. Just create yourself some nice split and join routines like in perl. An even better method is to just link your application with perl or tcl, and use their routines to splits the strings into parts. The TOC server is written in C, for those of you who are curious.
 +
  
  

Revision as of 11:39, 9 October 2023

TOC Protocol
IntroductionTermsClients
Basic
TOC 1.0TOC 2.0
Tutorials
Sign On


TOC (Talk to OsCar) is a protocol, and a server which connects to the AIM service. At its core, the TOC protocol is string-based, and incapsulated in a FLAP packet. As the data transmitted is string-based, it is referred to as SFLAP.

Compared to OSCAR, TOC is more simple, however it is not as flexible and doesn't contain all the features of OSCAR. It does, however, contain the essential features to communicate with the AIM service: IMs, Chat rooms, Warnings, and Privacy Management.


FAQ

This FAQ was originally created by AOL, and is written verbatim. The NINA team has added some notes at the bottom of each answer.

What does TOC stand for?

TOC, pronounced /talk/, currently stands for TOC to OsCar for lack of a better acronym. Really it just has to do with the members of the TicToc project obsession with useless 3 letter meaningless words. Since TOC is just a proxy protocol, it kind of makes sense.

Note: TOC means "Talk to OSCAR", not "TOC to OSCAR".

How does the TOC protocol differ from the OSCAR protocol?

The TOC and the OSCAR protocol are very different. The TOC protocol is a high level abstraction of the OSCAR protocol. The TOC protocol is entirely string based while the OSCAR protocol is binary based. Since the TOC protocol is entirely string based there are NO network byte ordering problems, while the OSCAR protocol will require careful packaging of data. (This is excluding the 6 byte FLAP transport layer header, used by both TOC and OSCAR, and will require network byte ordering.) Finally, the TOC protocol is currently the only one officially released and documented.

At the protocol level currently there is nothing in TOC that isn't in OSCAR. However there are things in the OSCAR protocol that are not in TOC. For example TOC will probably never support directory look up, password changing, or other non "core" features. Obviously this translates to the TIC/TiK clients vs AIM clients.

Are there benefits to the TOC protocol vs OSCAR protocol? Well not really, except TOC is extremely easy to work with, and it is at least public. Once you create your OSCAR/TOC independent FLAP layer you don't have to worry about network byte ordering with TOC, which makes portability much simpler. String termination can still lead to memory issues, but a good split routine will solve that problem.

Note: Ironically enough, TOC does support directory look up and password changing.

What is FLAP?

FLAP is a low-level communications protocol that facilitates the development of higher-level, record-oriented, communications layers. It is used on the TCP connection between all clients and servers. TOC adds a few extra requirements to TOC which are documented in the PROTOCOL file.

Note: Check FLAP for more thorough information.

Where can I get more information on the TOC Protocol?

Download TiK and look in the PROTOCOL file included. TiK should always contain the latest PROTOCOL file, since the maintainer of TiK also maintains the PROTOCOL document. Most of the protocol and the ordering of messages is documented in this file. For support send your questions to the tictoc-users mailing list.

But strings in C are ...?

Many folks think working with strings in C is hard, inefficient, cpu intensive, buggy. While there are some gotchas to worry about, in most cases this is simply not true.

Working with the TOC protocol in C is only slightly harder then in a language that treats strings as first class object. Just create yourself some nice split and join routines like in perl. An even better method is to just link your application with perl or tcl, and use their routines to splits the strings into parts. The TOC server is written in C, for those of you who are curious.