RE: Missing interface that connects NSCoder to NSStream ?

[Vaisburd, Haim]

That was fast! :-)

Helge Hess wrote:

> We don't need another thread for that since its indeed obvious. 

You made it :)

> Finally I also found the JSON-RPC 1.1 specification:
>   http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html#Overview

Finally I looked there too... Before that I was mainly looking (and
talking
exclusively) about JSON-RPC-1.0. Ok, I shouldn't have deleted the
background.
Sorry. Will provide it in a second.

> Eg instead of fiddling with writing own protocol implementations, just
do something like:
>
>   GSXMLRPC *remote = [[GSXMLRPC alloc] initWithURL: @"http://
yourtargetapp/"];
>   id result = [remote makeMethodCall:@"doIt" params: nil timeout: 5];
>
> and you are done

And the other guy? The other guy is some sort of legacy database-like
system where
nothing can be really changed. It's it and not any kind of browser I'm
going to talk to.

Thus, we have a sort of object database system at work. It works on
unix, and everything
is custom, no conventional interfaces. There exist a GUI browser written
with Athena
- do not laugh, it was right choice at a time and it's a good
application, -
but I wanted to write a different one. Instead of learning and then
programming Athena
I though it would be great to use GNUstep. GNUstep works on our
Solarises. But it cannot
be attached directly to the system - different compilers, 64 bit may be
an issue too.

So I looked for a way to exchange data between the engine process and
GNUstep GUI process,
presumably running on same machine. The data is supposed to be
structured as one-dimensional
array of strings (request with parameters) or two-dimensional array of
strings (response
looks like typical database table).

I was looking at XML-RPC but at the same time discovered JSON-RPC, and
JSON seemed
superior to XML for *data* exchange in every way:
1. The data is much readable by a human, and I wanted to see those
tables in
   the text form too,
2. The parsing is easier because the type can be determined from the
first character,
   so it can be parsed in one pass reading one character at a time.

Since JSON-RPC page encouraged the use of plain sockets and since I was
going to connect
my client and server exactly with a local socket, I did not read what
they
said about HTTP that time - it seemed unnesessary.

Now I did, but still do not want to use it.

As far as I got, HTTP works with packets, and it sends the packet length
in the header. The packet contains full request or full response.
With this length all the talks about streams immediately loose sence,
indeed.

But imagine a different model - you connect client and server with
stream sockets
and write JSON-encoded dictionaries directly into it. You read one
character
at a time from the same socket assuming the JSON data, deserialise as
you read,
and when you restored complete dictionary you perform the command
(execute a request,
or accept a response).

Then you do not need HTTP protocol, but need to read one character at a
time
from a socket. I was very confused not seeing the equivalent of getc()
in GNUstep.

Then the plan became to write such serializer/deserializer twice: for
GNUstep
and for C++ and then start the real work: determining messages,
parameters etc.
Seemed easy to write it from scratch at first ;-)

Does direct writing JSON stream to socket and using a socket in the very
same
manner one would use a file - no packets, no extra headers - look
stupid?

> Eg just consider what happens if an error occures during the on-the- 
> fly serialization. You have little choices but to close the stream (or

> implements a complicated protocol which supports OOB data).

Or what if I get bad input? Is *that* the main reason to outrule the
case
without HTTP?

I can probably make something to skip to the next command, although
the version 1.0 JSON-RPC says to close the connection.

Thank you,
Tima