Thanks for that one, haven't had time to look into it yet, but I have
had time to think a bit about the interop problem.
An easier way out that would also result in a more general solution
would be to simply use the http server in PL and work on the contents
of POST variables, using JSON or plain literal lists as the data
format.
Some people might wonder about the list part since we're talking about
Java here but I have no intention of writing my application logic in
pure Java, I will use Clojure which is a lisp.
If special structures are avoided as elements in a list then a list in
Clojure will look exactly like a list in PL. So http-posting it to PL
and then having PL simply evaluate it should work while avoiding the
overhead of JSON.
In this way data can come from may sources, especially if JSON is
added as a format that could be handled, API's would be a breeze to
launch.
The downside is of course that it involves more overhead, but I'm
starting to get the feeling that it might be worth it.
Any thoughts on this (hopefully more people than Alex will chime in) ?
On Thu, May 27, 2010 at 2:05 PM, Alexander Burger <a...@software-lab.de> wro=
te:
> On Thu, May 27, 2010 at 11:45:57AM +0200, Henrik Sarvell wrote:
>> Now pretend I have a PL database that listens on say port 4040, could
>> it be possible to use the current Java interop code to pass data to
>> that database for storage?
>
> This is not directly supported by the existing interfaces, as
> 'Reflector' is itself a server which expects to be queried by PicoLisp.
>
> On the PicoLisp side nothing special needs to be implemented. On the
> Java side you need library that connects to the PicoLisp server, sends
> requests, and receives answers via "java/InOut.java".
>
> This is in fact very similar to what the old Java GUI applets are doing
> (mainly in "java/Pico.java"). These applets connect back to the HTML
> server on a dedicated port (passed via the HTML page as a parameter to
> the applet), and use the PLIO functions (in "java/InOut.java") to send
> events and receive layout and content informations from the server.
> Parts of the 'connect' method (line 36 in "java/Pico.java") and all the
> calls to 'IO.somefunction()' might be useful.
>
> You could simply send complete PicoLisp statements, packed into Java
> arrays. They will appear as lists in PicoLisp.
>
> But easier is probably sending the data items individually, as you then
> have better control over the type. For example, with 'prSym()' you can
> then send internal symbols (typically functions), directly executable on
> the PicoLisp side (I hope to don't forget about security ;-)
>
> For example, to call (collect 'nm '+Cls) on the DB server (not tested):
>
> =A0 IO.Out.write(BEG);
> =A0 =A0 =A0IO.prSym("collect");
> =A0 =A0 =A0IO.Out.write(BEG);
> =A0 =A0 =A0 =A0 IO.prSym("quote");
> =A0 =A0 =A0 =A0 IO.Out.write(DOT);
> =A0 =A0 =A0 =A0 IO.prSym("nm");
> =A0 =A0 =A0IO.Out.write(BEG);
> =A0 =A0 =A0 =A0 IO.prSym("quote");
> =A0 =A0 =A0 =A0 IO.Out.write(DOT);
> =A0 =A0 =A0 =A0 IO.prSym("+Cls");
> =A0 Out.write(END);
> =A0 IO.flush();
>
> So this is a bit tedious. If the PicoLisp server uses a dedicated port fo=
r the
> Java queries, and does not
>
> =A0 (while (rd)
> =A0 =A0 =A0(eval @) )
>
> but instead
>
> =A0 (while (rd)
> =A0 =A0 =A0(apply @ (rd)) )
>
> then you can send the arguments without quoting in a list (array):
>
> =A0 Object args[];
> =A0 // fill args with 'nm' and '+Cls', and possibly more
> =A0 IO.prSym("collect");
> =A0 IO.print(args);
> =A0 IO.flush();
>
> Hope this works ;-)
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
>
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
