需要退伍军人：ASIHTTPRequest 的历史
序言
[请求发布]; 该框架创建者博客上的文章，并且不可否认的是，他并不是 ASIHTTPRequest（从现在开始：ASI）的忠实粉丝首先，我想知道它是如何/为什么开始的。
我注意到的第一件事是，当阅读宣布创建 ASI 的帖子时 一个易于使用的 CFNetwork 包装器是第二段：
NSURLConnection 易于使用，但它无法提供有关上传进度信息的方法 - 如果您的应用程序碰巧涉及上传大文件，则这是一个皮塔饼。
获取关于积极开发和维护的 API 的过时的 Apple 参考资料并不是绝对微不足道的，因此我未能获得 2008 年之前的具体类的文档，但从正在形成的图像来看，上面引用的声明似乎 不正确：
当 ASI 宣布时，NSURLRequest 确实有一个返回 HTTPBodyStream 的方法 - 事实上，该方法可以追溯到 2008 年之前的某个地方，可能是 2006 年左右，但很难确定，因为随着时间的推移，Apple 参考的 URL 发生了很大变化，这使得使用 archive.org 变得相当麻烦。
因此，在这段相当长的序言之后，真正的问题是：
是否不可能以适当的时间间隔简单地轮询 HTTPBodyStream 来获取其 NSStreamFileCurrentOffsetKey 属性的值，或者是 ASI ，那个数千行 CoreFoundation 代码的庞然大物，是因为一个小小的疏忽而诞生的吗？
不管怎样，为什么在 iOS 3.0 中将上传进度回调添加到 NSURLConnectionDataDelegate 后，它仍然被维护/使用很长时间？
特别是因为那些真正从监控上传进度中获利的资源无论如何都应该进行流式传输...
如果有人询问下载数据的选项，我仍然会在 StackOverflow 上看到 ASI 的推荐 - 不管它与任何较新的版本都不能很好地配合Apple 的东西，例如 Twitter 框架或 ARC 及其产生的警告和静态分析问题。这是怎么回事？
感谢您的任何见解！
Prologue
In the aftermath of the [request release]; article on the blog of this framework's creator and — admittedly — not being a huge fan of ASIHTTPRequest (from now on: ASI) in the first place, I wonder how/why it ever started.
The first thing I noticed, when reading the post that announced the creation of ASI as an easy to use CFNetwork wrapper was the second paragraph:
NSURLConnection is easy to use, but it provides no way to obtain information about upload progress - a pita if your application happens to involve uploading large files.
It's not absolutely trivial to get at outdated Apple reference material on actively developed and maintained API so I failed to obtain documentation on concrete classes that predate 2008 but from the image that is forming, the statement quoted above seems to be incorrect:
When ASI was announced, NSURLRequest did have a method to return the HTTPBodyStream — as a matter of fact, that method dates back to somewhere well before 2008, probably 2006ish but it's hard to determine because the URLs for Apple's reference changed a lot over time, which makes using archive.org quite a hassle.
So, after this rather long prologue, here the actual question:
Is/was it impossible to simply poll the HTTPBodyStream for the value of its NSStreamFileCurrentOffsetKey property at suitable intervals or was ASI, that behemoth of several thousand lines of CoreFoundation code, born out of a small oversight?
Regardless of that, why was it being maintained/is it being used long after the upload progress callbacks were added to the NSURLConnectionDataDelegate in iOS 3.0?
Especially since those resources that really do profit from monitoring upload progress should be streamed anyways...
I still see ASI recommended quite a bit here on StackOverflow if someone asks about options for downloading data — regardless of it not playing well with any of the newer Apple stuff like the Twitter framework or ARC and the warnings and static analysis issues it produces. What's up with that?
Thanks for any insights!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我无法回答你问题的第一部分，但可以回答这部分：
不确定您到底看到了什么，但 ASIHTTPRequest 的当前 git master 版本：
不会产生任何静态分析问题，我不确定您提到的 twitter 框架问题，我以前从未见过有人提到任何问题。
I can't answer the first part of your question, but to answer this part:
Not sure exactly what you've seen, but the current git master version of ASIHTTPRequest:
I'm not sure about the twitter framework issue you mention, I've never seen anyone mention any issues before.