Re: URLAccess Stalls
Re: URLAccess Stalls
- Subject: Re: URLAccess Stalls
- From: Marc Krochmal <email@hidden>
- Date: Wed, 14 Dec 2005 16:55:39 -0800
Zack,
Practically every application Apple ships, including Safari, uses non-
blocking IO. The fact that Safari shows the spinning beach ball
sometimes is not related to this, and is probably caused by a bug.
Apple has invested lots of resources into the download engine used by
Safari. It's called CFHTTPStream and NSURLDownload and related
APIs. The URLAccess API was designed for a different time. It uses
Thread Manager, FSSpecs, Pascal strings, and other Mac OS 9 isms and
didn't fit Apple's future direction of using CoreFoundation types and
RunLoops. Apple likes to avoid duplication of effort when possible,
which allows us to focus our efforts on a single implementation that
can be leveraged in many other parts of the system. So today, Mail,
Safari, iChat, iCal, iTunes, Front Row, Help Viewer, Software Update,
Xcode, QuickTime, and many other Apple applications are using
CFHTTPStream and higher level libraries.
We highly encourage you to make the transition to CFNetwork. Here's
some sample code to get you started. None of it contains any
Objective-C.
<http://developer.apple.com/samplecode/CFFTPSample/CFFTPSample.html>
<http://developer.apple.com/samplecode/CFNetworkHTTPDownload/
CFNetworkHTTPDownload.html>
Best Regards,
-Marc
On Dec 14, 2005, at 1:54 PM, email@hidden wrote:
On Dec 13, 2005, at 1:20 PM, Marc Krochmal wrote:
On Dec 13, 2005, at 1:59 AM, Alexey Proskuryakov wrote:
On 13.12.2005 00:49, "email@hidden" <email@hidden> wrote:
I am pretty much done, except for the fact that URLAccess
stalls at random times!
This is how URLAccess broke for us in Tiger (worked fine in 10.3).
I have had a CFHTTP-based replacement ready by that time, but I
agree with
your rant wholeheartedly. And could add to it, but it's offtopic :)
We've been telling people to stop using URLAccess since 2002.
Your life will be much easier if you use CFHTTPStream instead, or
even better, use NSURLDownload. URLAccess could not be more dead.
-Marc
Well that stinks. I'm going to go on an off topic rant for a
second so humor me I guess :-P I think the reason the internet can
be so frustrating is that the basic infrastructure still is not in
place in (gasp) 2005. Sockets are a disaster and require a
lifetime of learning to get even the most basic functionality or
reliability. FTP stalls all of the time, and I have yet to use a
client that properly threads requests, does retries, synchs files,
etc. The closest was Retrospect, but there should really be a free
client out there that does this (perhaps from the Finder?). Safari
suffers terribly from the original design flaw of nearly all web
browsers, namely blocking IO (beach-ball cursors galore), and will
likely never be fixed. File sharing is a dog, especially if you
put a computer to sleep in the middle of something, although it has
gotten far better in 10.4. SMB is a dog, and I don't expect it to
really improve much, since it's not a KISS technology like FTP to
me. I remember when I first saw Apache and HTML in 1995 and I
thought "surely it can't be like this", but it was, so the progress
since has been tainted with that micromanagement philosophy (vs a
R.A.D. environment like HyperCard). NetSprocket/OpenPlay is close
to what a protocol "should be" but it has not progressed as much as
it deserves to, because most of the superhuman effort by the open
source people has been to get it to a level comparable to Apple's
version 10 years ago. The only decent chat apps are iChat and
Skype, but only barely, if you don't count audio skips. I can go
on an on. I think Apple has an opportunity here to fix the Tower
of Babel, but letting a core protocol like URLAccess slip is not a
good start. I was okay with letting the Display Manager slip away,
because it was always a dog, and luckily RezLib came along and
showed us all how managing displays should have always been. If
Apple wants to do something like that with NSURL and CFHTTPStream,
more power to them. But I don't consider URLAccess a dog. It's
actually pretty good at what it does, and it seems that letting it
slip was a political decision. Apple has a responsibility to
actively work on libraries, even when they are deprecated, to
ensure basic functionality and compatibility for existing apps.
What makes me so uncomfortable about this is that we as developers
have no say in what technologies Apple deems unworthy. Apple
pulled the plug on us when they dropped 8 bit window support in OS
X, and there are ways around that now like OpenGL, but at the time,
we felt abandoned and it took a year's work to recover. I just
hope that we have some kind of promise that just because an API is
PowerPC or c based, it won't be indiscriminately dropped in the
transition to Intel. I don't want to live in a world where the
only APIs are objective-c in xcode, no matter what the benefits
are. Apple needs to promise us this, loud and clear, like Googles
"don't be evil", or the move will be suspect. I just really cannot
emphasize this enough. Thanx,
----------------------------------------------------------------------
--
Zack Morris Z Sculpt Entertainment This
Space
email@hidden http://www.zsculpt.com For
Rent
----------------------------------------------------------------------
--
If the doors of perception were cleansed, everything would appear
to man
as it is, infinite. -William Blake, The Marriage of Heaven and Hell
_______________________________________________
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
_______________________________________________
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