site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 16-May-2007, at 18:44, Dan Shoop wrote: -- mo mcroberts :: mo@nevali.net :: http://nevali.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... As we all know FUSE is a project to implement ad-hoc filesystems in user space. Ad-hoc filesystems are, by nature, not readily suitable for production. Hence my comment. Furthermore if the filesystem was production quality it would most likely be implemented within the system, not a user application. User based applications don't lend themselves well as production services. I'm not entirely (at all) sure why “ad-hoc” is relevant here; it makes no difference to the way the code is implemented, it's simply a matter of use-case. FUSE is an enabler, nothing more, nothing less, and on that token the fact that it CAN be used to implement ad-hoc filesystems which themselves MIGHT be unsuitable for a production environment is completely immaterial. Hey, guess what. exec...() is used to execute programs on an ad-hoc basis. Some of those programs might be dangerous and unsuitable for production use. By your argument regarding FUSE, the supporting kernel-level functionality that provides the exec family of system calls should never have been implemented. (As an aside, the assertion that WebDAV via FUSE would somehow be a step backwards as compared to its current implementation is more than a little dubious: do you actually have any basis on which to make that claim—besides “it ain't broke”? Implementing a user-space filesystem handler in a manner designed specifically to enable user- space filesystem handlers to be used seems anything but a step backwards). This email sent to site_archiver@lists.apple.com