• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Multipart POST using NSInputStream subclass
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: Multipart POST using NSInputStream subclass
      • From: Dave Dribin <email@hidden>
References: 
 >Multipart POST using NSInputStream subclass (From: Dave Dribin <email@hidden>)
 >Re: Multipart POST using NSInputStream subclass (From: Quinn <email@hidden>)
 >Re: Multipart POST using NSInputStream subclass (From: Dave Dribin <email@hidden>)

  • Prev by Date: Re: Multipart POST using NSInputStream subclass
  • Next by Date: Re: Multipart POST using NSInputStream subclass
  • Previous by thread: Re: Multipart POST using NSInputStream subclass
  • Next by thread: Re: Multipart POST using NSInputStream subclass
  • Index(es):
    • Date
    • Thread