We currently have two different systems that can’t easily be bridged,
effectively doing the same thing, but supporting different sources:
NSStream can work with files, data, and network streams (created by
NSURLSession and other high-level API).
NSFileHandle can work with files, pipes, stdin/out/error, file
descriptors, and due to the latter, sockets created with lower level
API.
When designing new API, I am torn between which of these two interfaces
I should support. Semantically I like NSInputStream if I have an API
that consume data, but this choice means my API cannot be used with
pipes, something which is quite useful for interprocess communication /
NSTask, nor with stdin, something I frequently consume in CLI tools.
OTOH streams do support “bounding” so it’s easy to create
self-contained filters and insert them into a stream.
Any thoughts on this? Have you selected one of them in your API only to
regret it later?
I think introducing a class method to NSStream that creates a read/write
stream from an NSFileHandle would go along way. Why has Apple never had
this need themselves (to make it part of the public API)?
It’s probably worth also mentioning blocks, today many things that are
“streams” are instead handled via callbacks, which makes the API
easier to use for majority of cases, but it is less formalized, so
harder to make reusable components to process such (stream) data.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
