wiredfool

Whenever I see the SCNS acronym I can’t help thinking of SCMODS. These are just cross wired in my brain. That happens a lot with initials and acronyms for me. Brands get mixed up, domains get crossed. Sometimes it’s even funny.

So to those marketers out there, if you want me to accurately remember your widget, make sure that it’s not confusable with obscure pop culture references. Or the code fragment manager (.cfm).

***Apple

Mmmmm xserve. I want one. Rather, I’ll take two, they’re small. I’ve got a dual 800 as my best server right now. It’s nice, but it’s big. And I’ve got a gaggle of other assorted g4’s hanging around. For what I’m doing, bandwidth to memory seems to be important, as well as the size of L3 cache.

The keys to the xserve are the DDR ram, lots of drives all on different controllers, lots of cache (2 meg per). It’s got bandwidth in all the important places, at least compared to what I’m working with now. Oh yeah, and it’s got a bit of processor too.

I still have a couple of questions about the storage subsystem and how it interacts with the software raid. Specifically, how can I split the 4 drives? 1 system + 3 raid 5? Raid 0+1? If I pull a (failed) drive and put in a spare will it sync up while on line? Are they going to require that I send them my firstborn?

I also find it interesting that it has a basic vga card and 9 pin serial for kvm or serial console access.

Sorry to those who’ve tried to log in to this site recently and failed. I did a database transplant on the membership and didn’t get everyone imported into the new system. I think things are working now. At the very least, things are working better than they were.

***Frontier TOC

The next revision to the ftocSuite should put it in the tcp.im drivers table. The functionality is going to be the same, but all of the scripts have been moved around a bit. All of the callbacks are now parsed through the new callback parser that was introduced on Friday. All of the outbound action scripts have been collected in their own sub table. And of course, there is the simple tcp.im interface on top of it all, if that’s all you need.

a scratchpad, a little bit of a brain dump.

***Notification, The scalability issue

At some point we’re probably going to be limited in the number of instant messages that we can send out.

Im’s are a 1:1 medium, im chat rooms are a many:many medium. In theory, a workgroup could subscribe to a chatroom, and as long as a bot held it open, could participate in a messaging medium where you could sent to all of the members of the room as easily as sending one im to an individual. There’s a little bit of hairy code required to make keep everyone in the room invited, which may turn out harder then just running down the list of people who want notification.

I haven’t seen this call in the api, but I suspect that lurking out there somewhere is a Send Message to all buddies method. That would make subscription lists essentially buddy lists, and once again making notification a single sent message.

***The 2k limit.

Aim has a 2k message limit, but we don’t have to be limited to AIM or other size limited channels. We have http. Aim’s strengths are that it’s a lightweight bus for quick messages between entities that are at unknown locations across the net. The only thing that we do know about them is that they have an open tcp/ip connection to AOL’s servers. this implies that the other end most likely has web access of somr form or another.

We can use an out of band data chunk to makeup for the small size limit, at least when sending from radio or a full peer frontier system with the http server running. We can either: upstream the body/attachment to /upstreamBase/imblobs/string.md5(some unique key) or map a url to the body in the frontier case. The other side would see the “big im rpc” message with the associated url, grab the content, and process from there. The hash is so that we can put content in a directory without having others poking around and having a likelyhood of finding anything. If there’s any response, or after some timeout, the sender can drop the link or delete the upstreamable file.

It’s unclear if we’d want to encode this in a im message or a gotourl message (at least from the aim case)

***Isomorphisims

An aimuser/pw/connection thread is similar to a service in user.inetd. User.inetd opens a listener for connections, IM opens a tcp connection then listens for packets from the AIM server.

The various messages that can be sent across (chat room, im, gotourl, etc.) are similar to the get/post/any methods of the http responder. By this analogy, mainresponder.respond is called by the any method of the default responder, the particular on_im_in method would be called by the im responder that picks up the request.

Does it make sense to design the im responder system so that it assumes that it will be trivial to run more than one resonder on different usernames? Prehaps pointing at a different responder table?

If we want the driver structure to take more than one connection in stride, we’re going to want to pass the address of the connection info so that the send method will be sending from the correct screenname. (eg, send(adrData, username, message)). That change is goign to have to percolate through the entire responder hierarchy.

Alternatively, we could set up a page table for the response, and store the pointer there. Any item that really needed to get to the connection info could get it through the pagetable. Or. If the im system needs it, it could set up the page table before calling into the tcp.im.server method. (this is sort of predicated on the threaded response model.)

***The other methods.

Almost all of the work and talking we’ve done up to this point has been on the on_im_in, do_send_im basis. Simple is good, and there is a lot that can be done with these. The other interesting api areas are in the chatrooms. We can certainly program a bot that will enter a chat if invited, or set up a chatroom and invite others.

I’ve updated “Frontier-Toc”. There are some bug fixes and a parsing class for callbacks in this release.

As a demonstration of how to use the system, I’ve got an im-> blog bot (ftocBlogger) that when configured, will route instant messages from an authorized user to your blogger api supporting weblog. You do need today’s release of the ftoc.root. Most of the configuration should be self explanatory if you’ve set up the blogger API before. Oddly enough, There are about as many items of configuration as lines of code.

***Updated

I’ve found an encoding error that was preventing certain common characters (e.g. “) from passing properly, which tended to prevent html from working properly. The fix has been uploaded.

Version 0.21

• 5/10 Fixed encoding error that f**ed up html.

Version 0.2

• 5/10 Added a parsing class so that callbacks can be written using logical parameters, rather than the “data” string.
• 5/10 Added logging levels and took out some of the logging of expected occurances.
• 5/10 Callbacks are now called in a threaded fashion.

No IM development last night, as I got to see the Mariners try to lose a game to Toronto. When the opposing pitcher walks 3 to load the bases, it helps to be able to manufacture a couple of runs out of it. Same for when he pitches 8 straight balls to open an inning.

A little gardening to round out the day. Family and other interested people can check out some more pictures of the new plantings.

I’ve just released Frontier-TOC, a Frontier/Radio Userland tool that implements one of the connection protocols to the AOL Instant Messenger Network.

This is the first release, and as such is still only interesting to developers. It can be useful for writing chatbots and other automated bits. It is not a full chat client.(At least, not yet)

There is a simple echo bot included with the download so that you can see the basics of how to connect and write an incoming IM handler.

*** Update

As of August 2002, this has been released in the Frontier and Radio Userland update stream as part of tcp.im. Further updates to this code are unlikely.

Version 0.21 Released 5-10-2002
Download. Updates

Frontier-TOC is a Frontier implementation of the AOL TOC protocol, one of the two that is used for AOL Instant Messaging. It enables scripters to write chatbots and other IM clients that work in Userland Frontier or Radio Userland. This implementation is a direct port of the PyToc 1.3 module by Jamie Turner. Frontier-TOC is released under a BSD license.

The TOC protocol spec has been published under the GNU public license and has been implemented in several open source chat clients. The other protocol, OSCAR, is used in AOL’s clients and has not been published. The OSCAR protocol is occasionally manipulated to break reverse engineered clients.

***Quickstart

Put it in your tools folder. Open ftocTest.startThread, and edit the screenname and password parameters. Run it and you should be able to IM yourself from another account.

***How to program it.

There is a basic echo bot implementation in ftocTest. It provides a setup script and a callback for incoming instant messages.

At a minimum, you will want to implement a on_IM_IN callback that will be called whenever an incoming im message is received.
One sample that strips any html and pongs back:

on on_IM_IN (adrSelf, data) {
	local {
		screenName = string.nthField(data, ':',1);
		message = string.mid(data, sizeOf(screenName)+4, infinity)};
	message = ftocSuite.strip_html(message);
	ftocSuite.do_SEND_IM(adrSelf, screenname, "Pong! You Said: " +message);
	return(true)}

The following code snippet (currently living at ftocTest.startThread) will start a bot using ftocTest.self for internal data storage. The go command logs into AIM and starts a thread to listen to the connection. The adrSelf parameter should be a location in the ODB, since it will be referenced by multiple threads.

local {
	adrSelf = @ftocTest.self};
ftocsuite.__init__(adrSelf, "screenname", "password", @ftocTest.callbacks);
ftocsuite.go(adrSelf)

More documentation to follow. For now, look at the code.

***Warnings and Caveats.

This is a second release. I am pondering changing some of the interfaces to make it a little easier for Frontier programmers. Documentation could charitably be called sparse. It does not make lattes yet.

***About the Port

This is a direct port of the Python class, and as such has some pythonisims that may not be familiar to most Frontier developers. Object orientation has been glossed over by providing a table of callback scripts and a table of instance values. Instead of function calls like objectName.functionCall(parameter), the calls look like ftocSuite.functionCall(adrSelf, parameter).

The most fiddly bits of the translation were that Frontier provides fewer binary packing tools than Python, and an isolated case of Frontier being 1 based instead of 0 based. Oddly enough, not knowing Python was not that much of an impediment.

***To Do

• I want to work on the pythonisims to make this look a little more like normal Frontier code.
• Better handling of network errors such as timeouts and dropped connections. Also need to figure out non-idle ping rates.
• Track updates to Py-toc since version 1.3

***Legal

Userland, Frontier, Radio Userland and AOL are trademarks of their respective holders. This is a derivative work of code copyright 2002 by Jamie Turner which was released under the BSD license. Frontier-TOC is copyright Eric Soroos, 2002 and released under the BSD license. This means that you are free to download it, use it, modify it, release it, or sell your changes. I can call you Betty, and Betty, when you call me you can call me Al. Just don’t strip out any copyright notices.

Tonight, at the Skansonia, Jason Webley returns for what is likely to be another summer of concerts.

What this time? Last time it was a new look, a few new songs, and a few old ones mising in action. Perhaps a new cd? Maybe the old drinking songs?