On Wed, Feb 25, 2009 at 1:16 PM, Kyle Sluder <kyle.slu...@gmail.com> wrote:
> How so? Resource loading? I guess it was less of an issue back in > the NeXT days. But I've got ten machines in my lab, and an Xserve > serving out /Network/Library... why can't I use /Network/Applications > and have it Just Work(TM)? Well, see my last response for the general overview of my reasoning. For specifics, though, consider that your setup is not the only network topology. Imagine a complicated app with many resources (its UI divided up into many nibs like Mail.app, and different sounds and plug-ins, etc.). To mitigate this problem so that it "just works" (as long as you can initially launch the application successfully), the application would have to load *everything*, which obviates most of the benefit of separating things into separate nibs, loading them only when needed. Obviously, this is even less desirable on a larger app that's being loaded over the network (loading everything takes longer). > I'm not all that worried about network interruptions. Must be nice. ;-) Even in the simplest topologies, they happen, so you *should* be ... Imagine a more complicated network topology. Many business and other institutions are larger and more complicated. The application server might be centrally managed by corporate headquarters, which may or may not be where you are. "We pay top dollar for the fastest point-to-point connections, so it'll load plenty fast," they say. What they don't think of are interruptions and they certainly don't tend to test even business-critical applications for robustness in this scenario ... how many man-hours are lost if the app fails ungracefully and whacks important data? More than that, though, are sprawling LANS with old equipment or power problems. Wireless networks which are prone to interference. Network interruptions *happen*, so while one network might be reliable, it's been my experience in the many business and institutes I've worked for that most aren't 100%. There's no planning for the many kinds of network environments on which your apps may be run, but you can at least plan for plenty of those environments being unreliable. In this case, your only choice is to load every resource the app needs at launch, or over-engineer the hell out of the app so that it intelligently handles every possibility that can arise from a resource not being available at runtime (and deciding whether it's safe to save data in that state, etc). Personally, my previous employers were an engineering firm who ran *everything* from the server. Apps, home folders, the works. A screwed up server installation (which the admin team refused to accept and handle for weeks) ended up corrupting drawings, losing business documents, and more until tens of thousands of dollars of man-hours were wasted and deadlines were missed. With sufficient screaming from management, the problem was fixed, but it highlighted the dangerous nature of the problem. Lessons learned: - Use portable home folders, rather than server-hosted home folders. - Install apps locally since many of them freaked the hell out when they couldn't load resources all the sudden, disallowing even a local save to their machine. - When your server(s) are everything, don't let them get so bad they bring down the whole f*****g company! - Even software developers can point out specific OS issues for the admin team ... ;-) Put simply, yes, there are other problems caused by intermittent network outages, but like those other problems, there're no simple solutions. You always sacrifice convenience for safety or the other way around. In this case, you can load all your resources or over-engineer the app to handle every 'missing resource' situation perfectly. -- I.S. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
