discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing interface that connects NSCoder to NSStream ?


From: Richard Frith-Macdonald
Subject: Re: Missing interface that connects NSCoder to NSStream ?
Date: Wed, 14 Mar 2007 07:43:31 +0000


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).

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).

Using streams in the first place is often an over-optimization. Eg if you just assemble a 32KB JSON packet using an NSMutableString you gain nothing in practice by using a stream. You loose a lot of convenience and implicit reliability. 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). With in-memory data you can just clear the so-far generate stuff and replace it with a proper error.

Even if you send something like a 2MB PDF file to a user a (language library level) stream is overkill, you can just tell the OS to send the file directly to the socket. This is magnitudes faster.

Greets,
  Helge

PS: I'm not saying that streams are bad, they are just a bit overused, especially in the Java world ;-)

I was just going to say something of the same sort ... so I'll just endorse what Helge said. IMO the block I/O model is generally simpler and more reliable, so should be used unless you need to do something where a single packet is huge and you don't have the space to assemble the whole thing in memory.

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]