Re: Multipart POST using NSInputStream subclass
Re: Multipart POST using NSInputStream subclass
- Subject: Re: Multipart POST using NSInputStream subclass
- From: Becky Willrich <email@hidden>
- Date: Wed, 16 May 2007 08:51:28 -0700
With this info, I was able to get my NSInputStream subclass to work
by providing the following stub methods:
- (void) _scheduleInCFRunLoop: (NSRunLoop *) inRunLoop forMode: (id)
inMode
{
// Safe to ignore this?
}
- (void) _setCFClientFlags: (CFOptionFlags)inFlags
callback: (CFReadStreamClientCallBack) inCallback
context: (CFStreamClientContext) inContext
{
// Safe to ignore this?
}
Of course, I don't know if it is actually safe to ignore these
methods. Is this something you can comment on? Will this break in
some weird way because I'm not providing an actual implementation to
these methods?
This is definitely not safe; much depends on exactly what your stream
is going to do, but I would expect this to fail in strange and
unexpected ways.
Thus, your options are:
1. safe but inefficient -- Create a temporary file and using a file
stream.
Well, at least it's memory efficient, right?
Right.
Nor could I find any bugs requesting a public API for implementing
a custom CFStream.
Is a custom CFStream needed? Also in my investigation yesterday, I
looked at how WebKit handles multipart forms. I found
FormDataStreamCFNet.cpp:
<http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/network/cf/FormDataStreamCFNet.cpp
>
This seems to provide a read stream with custom callbacks. Is this
using quasi-private APIs? Or could could I try this technique,
using the callbacks to get back into Obj-C land?
It's using quasi-private APIs, although you might find the matching
headers in the Darwin distribution of CF; I'm not sure. If you're
choosing between this and overriding NSInputStream's private methods,
this is definitely safer; the NSInputStream methods are still under
flux, whereas the relevant header in CF has been stable for some time
and the callback struct carries a version number, so it's much easier
for Apple to maintain backwards compatibility. Not that I'm promising
Apple will (it is a private API, after all), but at least it's possible.
OTOH, we do have a bug requesting that we make NSStream subclasses
play nice with CF (<rdar://problem/3222783>).
Should I create a bug that specifically mentions NSMutableURLRequest
and NSInputStream subclasses not playing nice?
You can if you'd like (squeaky wheels and all that), but I don't think
it's necessary - I believe the problem is well-understood by the
relevant teams.
- REW
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden