I've been told by at least one person that what I wrote didn't make
any sense. I blame it on the fact that I was watching Disney's Robin
Hood as I wrote it.
Here's are two examples, first retrieving a string that can be
unescaped complex JSON structure representing record number 12, and
second a simple capitalization function that treats it's argument as a
single non-linebreaked string. > means sent over the pipe, < means
returned over the pipe.
getrecord 12
< {name: 'Toph', website: 'http://cyll.org'}
capitalize foo bar
Foo Bar
The key is keep it lightweight, and parameters and returns are parsed
on a per remote function basis. Of course we document the the
protocols thorougly on our wiki, wrap both ends with a good stub
library/command server, and test the result comprehensively.
-Topher
On 7/17/06, Topher Cyll <[EMAIL PROTECTED]> wrote:
Hey Chris,
Just wanted to chime in here. We do this a lot at work. We have an
enormous quantity of Perl code written over the years, and we often
connect it to Ruby code. We use this exact technique and have a
calling convention of master/target where the master calls function
"foo" with args "param1" and "param2" like this:
foo param1 param2
The function name is everything up to the first space, everything
after that is passed in as a string. The implementations of the
functions are responsible for unescaping and parsing their own args.
The functions then return a line of results (escaped as necessary).
YAML or JSON are good complex escape formats if you need them, but we
often get away with simple strings.
Anyways, it's a pretty good system. The two things you have to watch
out for are making sure you have the sockets set to flush on output
and making sure you don't get into a deadlock problem where each side
is waiting on the other. It helps to make sure you only allow one
function to be called at once and make each function proxy parse it's
own return values. =)
Also, we might want to turn the evangelism on this list down a notch.
Everyone here likes Ruby enough to subscribe to the list and everyone
here is smart and rational. It's probably not productive to second
guess each other's designs without knowing all the details...
Good luck, Chris!
Topher
On 7/17/06, Chris Dawson <[EMAIL PROTECTED]> wrote:
> Yes, in fact, Ben M. is correct. The perl code is definitely much
> more complicated than what I put into the email. I didn't want to ask
> everyone on the list to sign an NDA.
>
> :)
>
> Chris
>
> On 7/17/06, Ben Matasar <[EMAIL PROTECTED]> wrote:
> > > > And I really have to ask why you need to fork a perl one-liner in your
> > > > ruby :-) If ruby's C API is so sweet and it has threads, just embed a
> > > > perl interpreter in a thread.
> > >
> > > Or just do whatever it is in Ruby ;)
> >
> > I realize you guys are joking, but I'm sure the work Chris actually
> > needs to do is in perl, and it's not a one liner. I have a piece of
> > code that needs to call Geo-Coder-US [1] as part of a larger app, and
> > reimplmenting that in ruby is outside the scope of my project ;).
> > CPAN is your friend.
> >
> > Ben
> >
> > [1] http://search.cpan.org/~sderle/Geo-Coder-US/
> > _______________________________________________
> > PDXRuby mailing list
> > [email protected]
> > IRC: #pdx.rb on irc.freenode.net
> > http://lists.pdxruby.org/mailman/listinfo/pdxruby
> >
> _______________________________________________
> PDXRuby mailing list
> [email protected]
> IRC: #pdx.rb on irc.freenode.net
> http://lists.pdxruby.org/mailman/listinfo/pdxruby
>
_______________________________________________
PDXRuby mailing list
[email protected]
IRC: #pdx.rb on irc.freenode.net
http://lists.pdxruby.org/mailman/listinfo/pdxruby
