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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
