Re: Missing interface that connects NSCoder to NSStream ?

[Helge Hess]

On Mar 14, 2007, at 20:16, Vaisburd, Haim wrote:
> What I miss in both techniques though is the I/O buffering that gives
> getc(), ungetc() or peekc() and putc() interface.

If you really want to have a full fledged streams library, give  
NGStreams a try. It supports all your requirements, it has the  
lookahead stream, supports non-blocking IO, character streams,  
buffering, sockets, files, etc etc.

And if you use a packet based protocol like HTTP beneath JSON you  
don't need any peekc, because you have random access inside the  
packet anyways. Thats BTW the way JSON is used 99.9999% of the time,  
namely on top of XHR.

Finally I also found the JSON-RPC 1.1 specification:

  http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html#Overview

which does the obvious thing, it specifies that *HTTP* is to be used  
as a transport. No word of "JSON-RPC over stream connections" anymore.


> > I also strongly agree with Helge's earlier comments that XML RPC is
> the obvious solution
> Too bad, I do not understand why. But I want to.

We don't need another thread for that since its indeed obvious. We  
are busy discussing low level IO details for hours while you already  
have fully functional XML-RPC libraries which do all the work for you.

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, or this one:

  http://sope.opengroupware.org/en/docs/snippets/xmlrpc_client.html

or any of the other implementations which are available for years.


Note that I would find it quite interesting to implement a JSON-RPC  
class, but this just for the pure fun, it makes absolutely no sense  
in the real world unless you communicate directly with a browser :-)

Helge
--
Helge Hess
http://www.helgehess.eu/