I am writing a cocoa application in which I want to download a file from a webserver. What will be the most convenient method to go about doing this? Should I go in for NSSockets or a NSUrlRequest? Or is there any other easier way to achieve this?
If you want to load the contents of the file into memory, many of the Cocoa data classes such as NSString, NSData and even NSDictionary have initWithURL: methods, which initialize directly with the contents of a web request. They're very easy to use, but they're not very flexible or provide for good error handling. NSURLConnection provides a more flexible way to load data if you need it.
If you want to download the file directly to disk, then NSURLDownload would be the best bet.
A word of warning: The initWithURL: methods are blocking, which is a big problem if the file is large, the server is slow, the user's internet connection is slow, etc. Don't call them from the main thread.
You also don't get any progress reporting, so when the download is slow, you have no way to tell the user how far along it is or how much longer it will take.
In almost all cases, you should use NSURLDownload or NSURLConnection instead.
The simplest thing to do is probably use NSURLDownload with NSURLRequest.
NSURLConnection is good if you want to get data from the web service into an NSString or NSData. Make sure you make asynchronous calls and handle errors and data in the NSURLConnection methods
Here's a good example for REST-style calls
http://kosmaczewski.net/2008/03/26/playing-with-http-libraries/
NSURLConnection does give you the most granularity, but be careful with NSURLConnection's sendSynchronousRequest() method. It leaks memory each time (have attached the XCode Leak Instrumentation tool and run it to prove it to myself) and gives weird HTTP 204 responses for no reason at all on occasion. I've blogged about this here
And another way is using libcurl, which comes preinstalled on any OS X system. You'd better make sure System Settings like proxies etc. are respected though if you use this approach.
Related
I have registered a custom file provider as static file provider, but it seems to be overridden. I never get any calls to IFileInfo.CreateReadStream, but the files are still being served. The thing is I'm trying to add mem-caching for a few commonly read files, so I was implementing this in my custom file-info class on first read. But now it seems that this is overriden by IHttpSendFileFeature. This is not at all very clear. What is it that IHttpSendFileFeature does that is better than basic CreateReadStream+CopyTo? Is it implementing some kind of caching itself? Perhaps I shouldn't try add custom caching here at all. I'm not sure if file-caching is done elsewhere in the pipeline already, and perhaps much better? I'm using Kestrel on .NET 6.
I don't want to read these files from disk on every request since I'm running this on a server with mechanical discs. If I was running this with SSD's I guess I wouldn't have to worry that much about this, I mean since reads are so fast on SSD already. But also, I assume the OS do a bunch of file-paging/caching as well? So perhaps I should just skip all custom caching altogether?
Try to remove the following
app.UseStaticFiles();
which calls
app.UseMiddleware<StaticFileMiddleware>();
If you remove UseStaticFiles() and instead call
app.UseMiddleware<MyStaticFileMiddleware>();
The original StaticFileMiddleware should no longer be called.
Your Post is a little unclear to me. How do you Serve those files?
The Services / Features you describe are not registered in the default service collection.
I am upgrading my iOS app to iOS8 and I want to make use of NSURLSession, but my project requirement is making synchronous calls to the server. It's done simply using NSURLConnection synchronous methods. But I can't find any source about making synchronous calls using NSURLSession. In fact, I read some blogs suggesting to stick to NSURLConnection. Any ideas about synchronous communication using NSURLSession?
Synchronous use of NSURLConnection is legal, but only on a background thread. This feature was misused, however, and was never really necessary; Apple is right to abolish it. You should not "stick to NSURLConnection"; it will be deprecated and withdrawn. Instead, you should rethink your approach here.
I am trying to port Wine 1.7.13 to modern Cocoa. I am considering running Windows binaries in an XPC service’s process, for security isolation and crash-proofing. However, there is one problem: To the best of my knowledge, XPC services are singletons. Only one XPC service process is allowed to be running at a time. This is a problem because, if I use threads to enable multiple Windows binaries to run at once, a segfault or other hard crash in one Windows binary would cause all the other binaries to crash with it.
As mentioned here, it is generally understood that the above assertion is true. If that is so, it would seem that I cannot implement this sort of isolation within a single XPC service process.
My other alternative is to use sandbox inheritance (having the GUI application fork and using more traditional IPC to have the Windows processes talk to each other) instead of an XPC service. What are the pros and cons of using that instead of an XPC service? I understand that processes that inherit their parent’s sandbox does not get to have its own entitlements. What other drawbacks are there?
I also understand that Apple discourages the use of sandbox inheritance in favor of XPC, but it is still an available design decision. They must have kept it around for a reason. Would a sandboxed Mac App Store app be able to use sandbox inheritance in this fashion?
I am going through the same decision. I had my heart set on XPC services, but upon discovering that there would be a single XPC Service with multiple connections, I cannot use them (my XPC Service will use plug-ins provided by third-parties so I want to keep them apart, and also the XPC Service will use libraries that might not clean-up properly, so I want to be able to dispose of them while keeping the UI stable - well I shouldn't have to justify this - I want one-process-per-job and that's that).
I am considering the normal sub-process model using posix_spawn() (I think this behaves better than fork() WRT to Sandboxing), CocoaAsyncSocket for the comms. I am going to see if I can replace the use of TCP/IP in CocoaAsynSocket with UNIX sockets to speed-up up comms (with the intent of contributing it back to the project if this works out). (UPDATE: this has already been done, some time ago by github user #jdiehl. See his socketUN branch and the discussion in issue #88 of the upstream repo).
For data marshalling I will use Google Protocol Buffers (UPDATE #2: Nope; not worth the hassle when NSKeyedArchiver and NSKeyedUnarchiver provide everything required out-of-the box. They may not provide data as packed as Google Protocol Buffers, but they 1) Don't require writing and maintaining, 2) Allow any class to participate by implementing the NSCoding protocol, and 3) Don't have to solve the issue of cross-platform data exchange.
The only possible disadvantage I can see is I don't know if file bookmarks can be passed to the subprocess and used (i.e. the UI opens a file or has a file dragged to it and wants to give access to the file to the worker process). I will update this answer with whatever I learn. (FINAL UPDATE: Passing the URL bookmark across the UNIX domain socket works fine, and the bookmark doesn't even need to be a security-scoped bookmark for this to work. There are no more impediments to this alternative to XPC).
Your assertion is incorrect about sub-processes not having their own entitlements; they do and are embedded into the executable and it must have "inherits sandbox" set for the sub-process to work correctly.
And the end-of-the-day the one-xpc-service-per-app is a show stopper so you have no choice but to find an alternative.
After being blown away by the greatness of irb and rails console, I am loving the dynamical parts of the language more and more. Now, I wonder if it would be possible for a Ruby application to update itself on-the-fly (if the write permission allows it). Can a Ruby application fetch an update and refresh itself? I have seen this functionality a lot in Apple applications and I know updates and fixes are something you must anticipate for when deploying an application.
Thank you for your feedback, comments and answers!
Sure. You can load a file that re-opens an existing class and alters behavior. There are a few ways to get the new code, too. Read it off disk, or have a socket that accepts connections and then eval the strings passed in. Or use HTTP: http://www.neurogami.com/articles/The_year_of_living_dangerously/
BTW, there's some risk involved with doing thngs this way. :)
I am sure answer for this question will be very subjective, I simply want to know what the options are out there (for building a proxy to load external contents).
Typically I used cURL in php and pass a variable like proxy.url to fetch content. Then make an AJAX call with Javascript to populate the contents.
EDIT:
YQL (Yahoo Query language) seems a very promising solution to me, however, it has a daily usage limit which essentially prevents me from using it for large scale projects.
What other options do I have? I am open to any language, any platform, key criteria are: performance and scalability.
Please share your ideas, thoughts and experience on this topic.
Thanks,
you dont need a proxy server or something else.
Just create a cronjob to fetch the contents every 5 minutes (or whenever you want).
You just need to create a script that grabs the content from the web and saves it (to a file, a database, ...), which will be started by the cronjob.
If somebody requests your page, you just need to send the cached content out and do with it whatever you want to do.
I think scalability and performance will be no problem.
Depending on what you need to do with the content, you might consider Erlang. It's lightening fast, ridiculously reliable, and great for scaling.