Extending Lua-RPC: questions about handling index and call events

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Extending Lua-RPC: questions about handling index and call events

jbsnyder
Administrator
Hi -

I've been working on adding some features to Russell Smith's Lua-RPC (http://q12.org/lua/index.html 
), which I've started putting up on GitHub here (functional, but not  
yet at a release stage: http://github.com/jsnyder/luarpc/).  It works  
by having a server listen for incoming requests for function calls.  
When one comes in it executes it and handles the return of data from  
the called function back to the client machine.  The client side is  
slightly more interesting, when one successfully connects to a server,  
one gets a handle userdata, which has an __index metatable.  When the  
table is indexed, a helper userdata is created with a __call  
metatable.  If this helper is called, the function name is transmitted  
to the remote Lua state and pcalled with a custom error handler.  
Depending on how things complete; results or error handling  
information are passed back to the client that initiated the call.

This works fairly well, but I would like to extend it so that in  
addition to calls to global functions, one could also call functions  
registered on tables, as well as just index remote variables or table  
entries to be able to inspect the remote state without having to send  
a function over to do that.

As it stands, one can do things like:
handle = rpc.connect()
res = handle.tostring(3.15)

The number 3.15 goes out to the server, the server does the tostring,  
and the resulting string is passed back to the client on the stack.

Now to the question:
I'd like to be able to do things like:
res = handle.math.cos(3.1)

or:

res = handle.sometable.someentry

and have the former perform the operation on the remote machine, with  
a result returned, or the latter give me what was in someentry on the  
remote machine.  What I'm unsure of however is how to know whether the  
sequence will end with gettable or call before returning.  Any  
suggestions on how to structure that to work for either situation?  It  
would be quite neat to be able to essentially work with a remote Lua  
environment just by prepending the handle.

Thanks in advance :-)


--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: (847) 448-0386


PGP.sig (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Extending Lua-RPC: questions about handling index and call events

Geoff Leyland
Hi,

That's a tough one - how would you handle


remote_cos = handle.math.cos
res = remote_cos(3.1)

or

table_I_want_transferred_in_its_entirety_now = handle.a_table

Can you work out a user's intentions without extra syntax?

You could obviously have some kind of evaluate function:

res = rpc.evaluate(handle.sometable.entry)

but I guess you're trying to avoid that because you didn't mention  
it?  Would lazy evaluation work?  You could not do anything until the  
object is used by a __call, __tostring, __add or some other  
metamethod.  There would be the usual problem with comparison  
operators, but it would work some of the time I think.

Cheers,
Geoff

On 4/06/2009, at 4:45 AM, James Snyder wrote:

> Hi -
>
> I've been working on adding some features to Russell Smith's Lua-RPC  
> (http://q12.org/lua/index.html), which I've started putting up on  
> GitHub here (functional, but not yet at a release stage: http://github.com/jsnyder/luarpc/)
> .  It works by having a server listen for incoming requests for  
> function calls.  When one comes in it executes it and handles the  
> return of data from the called function back to the client machine.  
> The client side is slightly more interesting, when one successfully  
> connects to a server, one gets a handle userdata, which has an  
> __index metatable.  When the table is indexed, a helper userdata is  
> created with a __call metatable.  If this helper is called, the  
> function name is transmitted to the remote Lua state and pcalled  
> with a custom error handler.  Depending on how things complete;  
> results or error handling information are passed back to the client  
> that initiated the call.
>
> This works fairly well, but I would like to extend it so that in  
> addition to calls to global functions, one could also call functions  
> registered on tables, as well as just index remote variables or  
> table entries to be able to inspect the remote state without having  
> to send a function over to do that.
>
> As it stands, one can do things like:
> handle = rpc.connect()
> res = handle.tostring(3.15)
>
> The number 3.15 goes out to the server, the server does the  
> tostring, and the resulting string is passed back to the client on  
> the stack.
>
> Now to the question:
> I'd like to be able to do things like:
> res = handle.math.cos(3.1)
>
> or:
>
> res = handle.sometable.someentry
>
> and have the former perform the operation on the remote machine,  
> with a result returned, or the latter give me what was in someentry  
> on the remote machine.  What I'm unsure of however is how to know  
> whether the sequence will end with gettable or call before  
> returning.  Any suggestions on how to structure that to work for  
> either situation?  It would be quite neat to be able to essentially  
> work with a remote Lua environment just by prepending the handle.
>
> Thanks in advance :-)
>
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> [hidden email]
> http://fanplastic.org/key.txt
> ph: (847) 448-0386

Reply | Threaded
Open this post in threaded view
|

Re: Extending Lua-RPC: questions about handling index and call events

jbsnyder
Administrator
On Jun 3, 2009, at 6:00 PM, Geoff Leyland wrote:

> Hi,
>
> That's a tough one - how would you handle
>
>
> remote_cos = handle.math.cos
> res = remote_cos(3.1)

As it stands, since what you get back when you index is a helper, that  
would execute the call on the remote machine.

>
> or
>
> table_I_want_transferred_in_its_entirety_now = handle.a_table
>
> Can you work out a user's intentions without extra syntax?

Right.  The user might want the table or they may just want to refer  
to it by a different name for later reference.

>
> You could obviously have some kind of evaluate function:
>
> res = rpc.evaluate(handle.sometable.entry)
>
> but I guess you're trying to avoid that because you didn't mention it?

I could, but I do rather like the simplicity of just working with it  
from the handle :-)

> Would lazy evaluation work?  You could not do anything until the  
> object is used by a __call, __tostring, __add or some other  
> metamethod.  There would be the usual problem with comparison  
> operators, but it would work some of the time I think.

That works for a fair number of things so long as there's a metamethod  
that can be hooked prior to an operation.

It does get weird with something like:

value_from_server = handle.some_value
value_from_server + local_value

or even things like:
value_from_server + handle.some_other_value

To me it would make the most sense to, when possible, pull both to the  
local environment, and then perform the local operation as it would  
with that type.  I wonder if that could be cleanly generalized  
somehow?  It would be nice to be able to do things like call  
math.cos(handle.some_remote_value) without having to explicitly copy  
it from the remote to the local state.  For things like this,

It doesn't have to perfectly handle every situation.  My main goals  
are to make it easy to execute functions on a remote session, and to  
make it pretty easy to get data from the remote environment for  
further local processing.

Perhaps the easiest approach is to do lazy evaluation, where the  
helper can handle __call (to call a remote function), __index (to  
index deeper into multiple layers of tables), and a method like "get"  
or "copy" that would take anything it knows how to serialize and copy  
it to the local stack.

Thanks for your comments and thoughts :-)

Any other suggestions?  (doing it all from a module without modifying  
Lua itself would be best)

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: (847) 448-0386


PGP.sig (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Extending Lua-RPC: questions about handling index and call events

Geoff Leyland
On 4/06/2009, at 12:25 PM, James Snyder wrote:

>> Would lazy evaluation work?  You could not do anything until the  
>> object is used by a __call, __tostring, __add or some other  
>> metamethod.  There would be the usual problem with comparison  
>> operators, but it would work some of the time I think.
>
> That works for a fair number of things so long as there's a  
> metamethod that can be hooked prior to an operation.
>
> It does get weird with something like:
>
> value_from_server = handle.some_value
> value_from_server + local_value
>
> or even things like:
> value_from_server + handle.some_other_value

These would both work wouldn't they?  Your helper's __add would get  
its (and the other operand's, if it was also a helper) value from the  
server and do the job locally.  (Which is what I think you wrote  
next).  I don't see a problem with that - am I missing something?  You  
*could* build a syntax tree and serialise that and send it to the  
server, but that'd be probably more complication than is necessary.

> To me it would make the most sense to, when possible, pull both to  
> the local environment, and then perform the local operation as it  
> would with that type.  I wonder if that could be cleanly generalized  
> somehow?  It would be nice to be able to do things like call  
> math.cos(handle.some_remote_value) without having to explicitly copy  
> it from the remote to the local state.  For things like this,

That should be possible, right?  You're serialising the call anyway,  
so if you can just serialise the helper too, it should be possible to  
handle it on the remote machine?

> It doesn't have to perfectly handle every situation.  My main goals  
> are to make it easy to execute functions on a remote session, and to  
> make it pretty easy to get data from the remote environment for  
> further local processing.

I think a combination of laziness and offering a "get" as you mention  
below would work fine.  There'd be some odd corners when you weren't  
sure if you needed a get or forgot one, but that wouldn't be too bad  
would it?

> Perhaps the easiest approach is to do lazy evaluation, where the  
> helper can handle __call (to call a remote function), __index (to  
> index deeper into multiple layers of tables), and a method like  
> "get" or "copy" that would take anything it knows how to serialize  
> and copy it to the local stack.
>
> Thanks for your comments and thoughts :-)
>
> Any other suggestions?  (doing it all from a module without  
> modifying Lua itself would be best)

Although the goal is completely different, this has a lot in common  
with rima's late bound symbolic math stuff - which is far from elegant  
or finished at the moment - so I'll look forward to seeing what you  
come up with.  Rima does have an eval, and it includes the  
"connection" (called a scope), so, in your context you'd have  
something like:

local a, b = rpc.helper"a, b"
local e = a + b.some_value

local res1 = rpc.eval(e, connection1)

and then you could ask another server/scope the same question

local res2 = rpc.eval(e, connection2)

I doubt that there's any use for that kind of functionality in what  
you're doing, but I'm pleasantly surprised that some of the insides  
are so similar.

Cheers,
Geoff
Reply | Threaded
Open this post in threaded view
|

Re: Extending Lua-RPC: questions about handling index and call events

jbsnyder
Administrator

On Jun 3, 2009, at 8:20 PM, Geoff Leyland wrote:

> On 4/06/2009, at 12:25 PM, James Snyder wrote:
>
>>> Would lazy evaluation work?  You could not do anything until the  
>>> object is used by a __call, __tostring, __add or some other  
>>> metamethod.  There would be the usual problem with comparison  
>>> operators, but it would work some of the time I think.
>>
>> That works for a fair number of things so long as there's a  
>> metamethod that can be hooked prior to an operation.
>>
>> It does get weird with something like:
>>
>> value_from_server = handle.some_value
>> value_from_server + local_value
>>
>> or even things like:
>> value_from_server + handle.some_other_value
>
> These would both work wouldn't they?  Your helper's __add would get  
> its (and the other operand's, if it was also a helper) value from  
> the server and do the job locally.  (Which is what I think you wrote  
> next).  I don't see a problem with that - am I missing something?  
> You *could* build a syntax tree and serialise that and send it to  
> the server, but that'd be probably more complication than is  
> necessary.
Right, they would with the implementation of an __add.

>
>> To me it would make the most sense to, when possible, pull both to  
>> the local environment, and then perform the local operation as it  
>> would with that type.  I wonder if that could be cleanly  
>> generalized somehow?  It would be nice to be able to do things like  
>> call math.cos(handle.some_remote_value) without having to  
>> explicitly copy it from the remote to the local state.  For things  
>> like this,
>
> That should be possible, right?  You're serialising the call anyway,  
> so if you can just serialise the helper too, it should be possible  
> to handle it on the remote machine?
Hmm..  So, executing the line above gives you the following bytecode:
main <test.lua:0,0> (6 instructions, 24 bytes at 0x1dd5530)
0+ params, 2 slots, 0 upvalues, 0 locals, 4 constants, 0 functions
        1 [1] GETGLOBAL 0 -1 ; math
        2 [1] GETTABLE 0 0 -2 ; "cos"
        3 [1] GETGLOBAL 1 -3 ; handle
        4 [1] GETTABLE 1 1 -4 ; "some_remote_value"
        5 [1] CALL     0 2 1
        6 [1] RETURN   0 1


This is tougher than the other metatable stuff because after getting  
the cos function onto the stack, locally, I'm putting a  
some_remote_value userdata for it to operate on locally.  
Unfortunately, it's not a lua number however, it's a userdata.  
Looking at how this is implemented in lua, I don't see how I can hook  
this in such a way that I can have that userdata behave like a number.

This, I suppose, is the crux of this issue: how do I know whether to  
push userdata onto the local stack, or to serialize the remote value  
and put that actual value on the stack instead?

handle.math.cos(handle.some_remote_value) wouldn't be as much of a  
problem, since I could push over the index events to get  
some_remote_value onto the remote stack for the remote cos.

I guess one way to deal with this would be to handle things this way  
for remote indexes:

if type is number, string, boolean, or nil:
        serialize it and put it on the local stack,
otherwise:
        provide lazy evaluation helper

There are probably a bunch of disadvantages I'm not thinking of here,  
but I think, for sure, I have to point the index to some sort of  
proxying function that actually gets the remote value, otherwise I'll  
end up with a local cached value on the local table (which would be  
undesirable if the value changed on the remote side and I wanted to  
poll it).

>
>> It doesn't have to perfectly handle every situation.  My main goals  
>> are to make it easy to execute functions on a remote session, and  
>> to make it pretty easy to get data from the remote environment for  
>> further local processing.
>
> I think a combination of laziness and offering a "get" as you  
> mention below would work fine.  There'd be some odd corners when you  
> weren't sure if you needed a get or forgot one, but that wouldn't be  
> too bad would it?
No, this might be a good way to make intentions explicit without  
making a huge hairy implementation that might require a fair amount of  
work whenever Lua gets updated.  It certainly has no downsides to  
inclusion even if the default behavior were extended to try and do  
something clever.

>
>> Perhaps the easiest approach is to do lazy evaluation, where the  
>> helper can handle __call (to call a remote function), __index (to  
>> index deeper into multiple layers of tables), and a method like  
>> "get" or "copy" that would take anything it knows how to serialize  
>> and copy it to the local stack.
>>
>> Thanks for your comments and thoughts :-)
>>
>> Any other suggestions?  (doing it all from a module without  
>> modifying Lua itself would be best)
>
> Although the goal is completely different, this has a lot in common  
> with rima's late bound symbolic math stuff - which is far from  
> elegant or finished at the moment - so I'll look forward to seeing  
> what you come up with.  Rima does have an eval, and it includes the  
> "connection" (called a scope), so, in your context you'd have  
> something like:
>
> local a, b = rpc.helper"a, b"
> local e = a + b.some_value
>
> local res1 = rpc.eval(e, connection1)
>
> and then you could ask another server/scope the same question
>
> local res2 = rpc.eval(e, connection2)
>
> I doubt that there's any use for that kind of functionality in what  
> you're doing, but I'm pleasantly surprised that some of the insides  
> are so similar.
Interesting, is Rima available somewhere?  I might be interested in  
taking a look just to see if I might learn a bit from the  
implementation.

I could see some advantage to doing something like what you describe  
above where you might have a client talking to multiple lua instances  
to either poll them for state information, or to do work on them.  If  
you wrap things with some sort of map function and use it to work on  
large chunks of data over a series of connections registered on a  
table or something.

I'm mainly working on this for use with eLua (hence the serial link  
protocol being supported (which is giving me some headaches) ), so  
that I can have a link to an embedded device and do development and  
testing while having the benefit of being able to get large quantities  
of data back to a desktop machine.  There might be benefit to being  
able to use this sort of thing to poll a bunch of embedded devices in  
succession over a network or wireless link.

Side note for those who might use this:
I make no claims about how well this code will deal with anything  
malicious.  Since it's fairly simple, it likely is possible to lock it  
down a little more tightly and deal with potential exploitation.  
Because of the way it is abstracted, you should be able to wrap the  
low level buffer writing code to add any layers one might want around  
the actual messages that are transmitted.  I'm working to make this as  
easy as possible to use on any sort of communication medium that one  
can read and write bytes to, since the embedded devices it will be  
used on could use a variety of different types of links :-)

Also, it does NOT deal with correcting endianness for the data  
transmitted, at this point, but I will likely deal with this in the  
future (hopefully automatically :-).

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: (847) 448-0386


PGP.sig (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Extending Lua-RPC: questions about handling index and call events

Geoff Leyland
On 5/06/2009, at 2:39 AM, James Snyder wrote:

>>> math.cos(handle.some_remote_value)
>
> Hmm..  So, executing the line above gives you the following bytecode:
> main <test.lua:0,0> (6 instructions, 24 bytes at 0x1dd5530)
> 0+ params, 2 slots, 0 upvalues, 0 locals, 4 constants, 0 functions
> 1 [1] GETGLOBAL 0 -1 ; math
> 2 [1] GETTABLE 0 0 -2 ; "cos"
> 3 [1] GETGLOBAL 1 -3 ; handle
> 4 [1] GETTABLE 1 1 -4 ; "some_remote_value"
> 5 [1] CALL     0 2 1
> 6 [1] RETURN   0 1
>
> This is tougher than the other metatable stuff because after getting  
> the cos function onto the stack, locally, I'm putting a  
> some_remote_value userdata for it to operate on locally.  
> Unfortunately, it's not a lua number however, it's a userdata.  
> Looking at how this is implemented in lua, I don't see how I can  
> hook this in such a way that I can have that userdata behave like a  
> number.

Sorry, I got that one wrong - I can see how  
handle.math.cos(handle.some_remote_value) could be done in one round  
trip to the server, but I agree that  
math.cos(handle.some_remote_value) is not going to work and I can't  
see a way around math.cos(rpc.get(handle.some_remote_value)).  You'd  
need some kind of c++ cast operator - maybe you could campaign for a  
__tonumber metamethod in Lua 5.2?

> This, I suppose, is the crux of this issue: how do I know whether to  
> push userdata onto the local stack, or to serialize the remote value  
> and put that actual value on the stack instead?
>
> handle.math.cos(handle.some_remote_value) wouldn't be as much of a  
> problem, since I could push over the index events to get  
> some_remote_value onto the remote stack for the remote cos.
>
> I guess one way to deal with this would be to handle things this way  
> for remote indexes:
>
> if type is number, string, boolean, or nil:
> serialize it and put it on the local stack,
> otherwise:
> provide lazy evaluation helper
>
> There are probably a bunch of disadvantages I'm not thinking of  
> here, but I think, for sure, I have to point the index to some sort  
> of proxying function that actually gets the remote value, otherwise  
> I'll end up with a local cached value on the local table (which  
> would be undesirable if the value changed on the remote side and I  
> wanted to poll it).

Does this mean you'd have to go and ask the server at each __index?  
But then, "for k, v in pairs(handle.some_remote_table) do..." wouldn't  
work either.  (Campaign for __pairs in Lua 5.2?)

>>> Interesting, is Rima available somewhere?  I might be interested  
>>> in taking a look just to see if I might learn a bit from the  
>>> implementation.

http://www.incremental.co.nz/download/rima-0.01.tar.gz

Just ignore all the solver stuff and have a look at the symbolic math  
stuff.  rima/ref.lua is probably where the interesting stuff happens.  
Rima does not do this nicely yet - it's more that I aim to have it  
looking like what you're talking about one day.

> I could see some advantage to doing something like what you describe  
> above where you might have a client talking to multiple lua  
> instances to either poll them for state information, or to do work  
> on them.  If you wrap things with some sort of map function and use  
> it to work on large chunks of data over a series of connections  
> registered on a table or something.
>
> I'm mainly working on this for use with eLua (hence the serial link  
> protocol being supported (which is giving me some headaches) ), so  
> that I can have a link to an embedded device and do development and  
> testing while having the benefit of being able to get large  
> quantities of data back to a desktop machine.  There might be  
> benefit to being able to use this sort of thing to poll a bunch of  
> embedded devices in succession over a network or wireless link.

Distributing workloads seems like an obvious use?


Reply | Threaded
Open this post in threaded view
|

Re: Extending Lua-RPC: questions about handling index and call events

jbsnyder
Administrator

On Jun 4, 2009, at 8:05 PM, Geoff Leyland wrote:

> On 5/06/2009, at 2:39 AM, James Snyder wrote:
>>>> math.cos(handle.some_remote_value)
>>
>> Hmm..  So, executing the line above gives you the following bytecode:
>> main <test.lua:0,0> (6 instructions, 24 bytes at 0x1dd5530)
>> 0+ params, 2 slots, 0 upvalues, 0 locals, 4 constants, 0 functions
>> 1 [1] GETGLOBAL 0 -1 ; math
>> 2 [1] GETTABLE 0 0 -2 ; "cos"
>> 3 [1] GETGLOBAL 1 -3 ; handle
>> 4 [1] GETTABLE 1 1 -4 ; "some_remote_value"
>> 5 [1] CALL     0 2 1
>> 6 [1] RETURN   0 1
>>
>> This is tougher than the other metatable stuff because after  
>> getting the cos function onto the stack, locally, I'm putting a  
>> some_remote_value userdata for it to operate on locally.  
>> Unfortunately, it's not a lua number however, it's a userdata.  
>> Looking at how this is implemented in lua, I don't see how I can  
>> hook this in such a way that I can have that userdata behave like a  
>> number.
>
> Sorry, I got that one wrong - I can see how  
> handle.math.cos(handle.some_remote_value) could be done in one round  
> trip to the server, but I agree that  
> math.cos(handle.some_remote_value) is not going to work and I can't  
> see a way around math.cos(rpc.get(handle.some_remote_value)).  You'd  
> need some kind of c++ cast operator - maybe you could campaign for a  
> __tonumber metamethod in Lua 5.2?
That, I think, would be quite nice to have for this situation. I did  
find this earlier discussion that suggests __tonumber (for different  
reasons), and includes a patch that modifies luaB_tonumber to try  
__tonmber:
http://lua-users.org/lists/lua-l/2009-02/msg00071.html

There are some upsides and downsides discussed there as well.

One idea that I have no idea whether it might work  would be some way  
of __index to be able to tell who is asking who is about to consume  
the value.  Such a mechanism could have interesting implications,  
certainly including possibility for good and evil.  I haven't really  
investigated to see what one has available through debug hooks when  
index is called, so this could be really messy or impossible :-)

Another way to do things would be to have index2adr optionally call a  
metamethod.  I don't know if this ever gets called early such that you  
might accidentally do pro-active rather than lazy evaluation.  Also,  
I'm sure such a change would potentially slow down everything else in  
Lua.

There's some interesting stuff here too, although I don't think it  
really solves the problem:
http://lua-users.org/wiki/TableScope


>
>> This, I suppose, is the crux of this issue: how do I know whether  
>> to push userdata onto the local stack, or to serialize the remote  
>> value and put that actual value on the stack instead?
>>
>> handle.math.cos(handle.some_remote_value) wouldn't be as much of a  
>> problem, since I could push over the index events to get  
>> some_remote_value onto the remote stack for the remote cos.
>>
>> I guess one way to deal with this would be to handle things this  
>> way for remote indexes:
>>
>> if type is number, string, boolean, or nil:
>> serialize it and put it on the local stack,
>> otherwise:
>> provide lazy evaluation helper
>>
>> There are probably a bunch of disadvantages I'm not thinking of  
>> here, but I think, for sure, I have to point the index to some sort  
>> of proxying function that actually gets the remote value, otherwise  
>> I'll end up with a local cached value on the local table (which  
>> would be undesirable if the value changed on the remote side and I  
>> wanted to poll it).
>
> Does this mean you'd have to go and ask the server at each __index?  
> But then, "for k, v in pairs(handle.some_remote_table) do..."  
> wouldn't work either.  (Campaign for __pairs in Lua 5.2?)
Hmm.. that would be true as well.  I suppose another alternative would  
be to serialize only tables that contain all serializable entries, but  
I think that starts getting too weird and inconsistent.

>
>>>> Interesting, is Rima available somewhere?  I might be interested  
>>>> in taking a look just to see if I might learn a bit from the  
>>>> implementation.
>
> http://www.incremental.co.nz/download/rima-0.01.tar.gz
>
> Just ignore all the solver stuff and have a look at the symbolic  
> math stuff.  rima/ref.lua is probably where the interesting stuff  
> happens.  Rima does not do this nicely yet - it's more that I aim to  
> have it looking like what you're talking about one day.
Thanks.  I will take a look.  I do have some interest in symbolic math  
stuff as well, though I don't end up using it a great deal in day-to-
day.

>
>> I could see some advantage to doing something like what you  
>> describe above where you might have a client talking to multiple  
>> lua instances to either poll them for state information, or to do  
>> work on them.  If you wrap things with some sort of map function  
>> and use it to work on large chunks of data over a series of  
>> connections registered on a table or something.
>>
>> I'm mainly working on this for use with eLua (hence the serial link  
>> protocol being supported (which is giving me some headaches) ), so  
>> that I can have a link to an embedded device and do development and  
>> testing while having the benefit of being able to get large  
>> quantities of data back to a desktop machine.  There might be  
>> benefit to being able to use this sort of thing to poll a bunch of  
>> embedded devices in succession over a network or wireless link.
>
> Distributing workloads seems like an obvious use?
Perhaps someone will take a look at it for uses like that at some  
point.  There are certainly already some models out there for  
concurrency in Lua.  I know the serialization and protocol here aren't  
necessarily new, but being able to manipulate other Lua environments  
as if they were a table seems like a powerful metaphor.

At least the path for doing this with functions seems fairly  
straightforward :-)

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: (847) 448-0386


PGP.sig (210 bytes) Download Attachment