[MLton] Serialization?

[Wesley W. Terpstra]

On Tue, Jul 05, 2005 at 09:46:44AM -0400, Matthew Fluet wrote:
> There really isn't any support for throwing some bytecodes over the wire 
> to another MLton application and start executing the bytecode in the 
> receiver application.  As with many things, the whole-program nature of a 
> MLton application means that almost nothing makes sense out of the context 
> of its whole-program.

Yeah, I know.
That's why I'm stumped... :-(

> The better way (at least in MLton) of implementing something like the 
> above is to write the client and server together as one application, 
> thereby sharing the same code and representation.

This won't help for what I'm trying to build.

In a publish/subscribe network, you have queries that you push into the
system to select 'notifications' or data pushed in by other nodes.

The idea is that the receivers self-select the data they want, the data is
not addressed to any particular nodes as in message passing systems.

So, requiring every node to have compiled the queries of all nodes isn't
really practical. The idea is that you have this infrastructure in place,
then add a client node who injects some query into the system.

> Alternatively, one could simply limit the FFI supported by the bytecode to 
> the FFI needed to implement the Basis Library.  We could easily ensure 
> that each bytecode interpreter on different platforms correctly handled 
> those C-functions, at the expense of excluding additional C-functions in 
> the user program.

This would be enough for my purposes...

> > ... for me, I just need to be able to call the 'main' function of the
> > bytecode with a parameter and recover the result. 
> 
> This seems more like remote program execution than mobile code; which 
> means that OS level solutions might work just as well.

Well, the idea is to be able to evaluate the query against a notification
and see if it matches. If it does, then that notification should be sent to
the client, otherwise not. Shipping code as the query is the fallback case
for where the query language (chosen because it can be optimized) cannot
express the query the user needs.

-- 
Wesley W. Terpstra