RE: Missing interface that connects NSCoder to NSStream ?

[Vaisburd, Haim]

On 14 Mar 2007, at 07:31, Helge Hess wrote:

> On Mar 14, 2007, at 01:57, Vaisburd, Haim wrote:
>> Does OPENSTEP/Cocoa offer better mechanism that works like C++ 
>> stream, i.e. let you disregard the source of data and concentrate on 
>> formatting?
>
> The "official" way prior NS*Stream was to assemble a packet in an 
> NSData and then send the NSData, eg using Mach port or NSFileHandle 
> (eg sendInBackgroundAndNotify).

Oh, sh*t, I missed the crucial line in NSFileHandle documentation:

    - (id)initWithFileDescriptor:(int)fileDescriptor

    You can create a file handle for a socket by using the result of
    a socket() call as fileDescriptor.

Yeah, yeah! I hope they meant "result of accept() and connect()" too,
did they? That will render what I had prevuously said to be 90% useless,
but please see below.

> (eg sendInBackgroundAndNotify). 

Richard Frith-Macdonald wrote:
> IMO the block I/O model is generally simpler and more reliable, so
should be used

Yes, totally agree, absolutely. Non-blocking reads/writes was _not_ why
I tried NSStreams. Moreover, I struggled with non-blocking NSStream IO
forcing
it to block, otherwise I did not know how to parse recursive constructs
in JSON.
So, no need for -sendInBackgroundAndNotify, -writeData would do.

I tried NSStreams because they seemed to provide an isolation from the
actual source of data, i.e. I liked the interface
  +getStreamsToHost:port:inputStream:outputStream:
  +inputStreamWithData:
  +inputStreamWithFileAtPath:
and GNUstep extensions:
  +getLocalStreamsToPath:inputStream:outputStream:
etc.

They made a lot of sence to me, I would only add a flag saying whether
I want blocking IO or not.
Now, having realised that NSFileHandle can work with any file
descriptor,
I think that, apart from NSData, file descriptors provide very similar
encapsulation.

What I miss in both techniques though is the I/O buffering that gives
getc(), ungetc() or peekc() and putc() interface.

Helge Hess:

> The historical reason is that NeXTstep was based on Mach which in turn

> was based on packet/message IPC. The Mach virtual memory system would 
> simply remap such a data section in memory to the target process on 
> the local machine (or forward the block to a remote machine 
> transparently).

We do not have this on Linux, Solaris, FreeBSD, do we?
Having a 4K buffer and read() on underflow / write() on overflow
seems good...

Ok, here is more important part:

Richard Frith-MacDonald:

> I also strongly agree with Helge's earlier comments that XML RPC is
the obvious
> solution for the application unless there is some important issue you
aren't
> telling us about which rules it out.

Too bad, I do not understand why. But I want to.
I'll send this question again in a separate mail to make another thread,
JSON versus XML is not related to NSStream problems.

Thanks a lot,
Tima.