Sagot
Any of you who know me would know how big of a fan I am of the Mozilla Desktop application framework. While I've found the highly XML driven JavaScript backed platform to be idea for cranking out service oriented desktop applications (and other types of desktop applications), I at one point had the thought a similar evnironment might be nice for web service and server side tool development. So, I spent the weekend a few weekends ago going through mozilla trying to get XPCOM, DOM, SOAP, etc out of Mozilla…I found, however, that it is virtually impossible to disentangle all of those things from xpfe. So I had another idea, one that was lighter weight and cut less corners…
Sagot is born
sagot
sag´ot n. answer, response, reply · sumagot, sagut´in (-um-:-in) v. to answer, to reply. Sagutin mo ang tanong ko. Answer my question.
Sagot, tagalog for "answer" or "response" (the "got" pronounced as the got "I've got to go"), is a light weight programming environment. It's development is moving very slowly currently, but the basic idea is such.
Provide an object oriented interface to glib, which is the multitasking framework GTK is built atop of. Second, provide interfaces to LibXML2 and LibXSLT, GDOME, and then SOAP/XML-RPC interfaces…and stuff it in a web server.
If this project gets completed is completely up to a whole bunch of outside influences, but currently I see no reason to stop development and the multitasking API is well underway.
Plans
The EventLoop? and EventContexts? are well under way, idle events are fully functional. Currently, the IO Channels are being implemented which will integrate with the EventLoop? allowing one to watch a socket or file and fire off events accordingly.
It doesn't really do a whole lot still, but I worked my way through all the GC issues and I got the basic event queue not only working but working well. I'm currently implementing IO Channels for sockets and files.
/* Existing */
var loop = new EventLoop(new EventContext() /* optional *)
loop.enqueue(object, "method", arg, arg, ...)
loop.run()
/* Soon to be implemented */
var sock = new SocketChannel(address, port)
loop.watch(sock, "read", object, "readMethod")
/* Non-blocking file system reads */
var readfs = {
read: function (chunk) {
sock.write(chunk)
},
}
I have yet to make up my mind about the watching API. it will be refined by practice, I sometimes find this is the best way to go about API design. Use it, and see if it comes short, then change it before it's too late.
I am also making careful considerations regarding filters. Filtering should be handled in a very simple fasion and I believe it's important, but at the same time I want basic filters that are commonly used to be able to be written in C and handed directly to sagot without hitting the spidermonkey runtime at all. I think filters should be really fast when they can.
The goal of this part of the project is to build something like POE, but faster, and more object oriented for JavaScript. It has similar features, Objects don't get collected until there are events or event sources left (similar to sessions POE - already implemented). Idle event juggling can be used to multitask even when you aren't waiting on I/O or allow I/O to be more responsive, without using multithreadding.
Unlike POE, you can prioritize I/O events over idle events, or prioritize other idle events over I/O, or any combination thereof.
I believe adding filters will be a good idea, because you cannot count on when remote buffers will be flushed. In POE, you use filters to collect data and make sure read events, and writes, only happen when the expected data comes across the pipe from each side. This gives you the ability to also make filters that create objects, or whatever you like. For instance POE::Filter::HTTP builds an HTTP::Request object, and the same thing would be possible in sagot (well, obviously it cannot be a HTTP::Request object, but it could be an HttpRequest? object). If this is implemented, very fast pure C (skipping the javascript engine entirely) line and stream filters will be implemented for the most common APIs. Only special filters will be needed.
It might be worth considering a design that allows stackable filters, or one filter that feeds another. This way say an HTTP, IRC, or SMTP filter written in JavaScript could use the C line filter in it's implementation easily. I have yet to make up my mind as to if this would be worth the effort, however.
Comments
Comment by bmk-Dobson3604@… on Mon Oct 23 00:15:24 2006
i liked your site
Comment by scott on Tue Mar 13 17:41:08 2007
Thanks, it's a little poorly maintained and stale but I'm trying to slowly work on fixing that.
Changelog
<pre>/trunk/sagot,5</pre>
