Mac App Store Compatibility
wby...@fadingred.com
Apps that use KFS should not violate any terms set forth by the App Store. Actually, that was one of the focuses during development.
Some important decisions that were made with the MAS in mind:
Private APIs — this is one of the biggest things that people focus on in regards to App Store approval. KFS does not use any private APIs.
Forking — while KFS could fork (and there would be some advantages), it doesn't since this isn't allowed in the MAS. There are potential advantages to forking to handle backend KFS stuff, but if that's explored it will likely be implemented as an option.
Portmapper — KFS is implemented with an NFS backend. The Mac OS X kernel does integrate with protmapper to properly handle mounting and unmounting of NFS mounts. While KFS could be enhanced by registering with the local portmap daemon, it does not because a user isn't explicitly requesting that an NFS server be run on their local machine. This basically falls under the realm of 'being a good citizen' but could have also been a point of rejection from the store.
The whole project is created as an embed-able framework, so it's really just like any other framework you would embed in your app bundle.
That's all I can think of. The code base isn't too big, so you can easily check it out and get a feel for what it's doing.
Whitney Young
FadingRed
wby...@fadingred.com
www.fadingred.com
Jeff Mancuso
For one, I like the idea of having Apple maintain the kext [NFS] - and
I doubly like the idea of getting into the app store [which ExpanDrive
currently cannot].
Have you built anything on this yet, such that you can test
performance at all?
-Jeff
wby...@fadingred.com
Yes we've tested it — we're currently using it in Senuti. We're still working out some features unrelated to KFS before we ship the next version of Senuti, but we've tested it in house a lot and have sent a build to customers who have had success.
Senuti was using MacFUSE and is now using KFS to handle a filesystem with mostly larger files (> 5MB). In our tests, the KFS implementation was faster than MacFUSE. I don't remember exactly what the percentage was, but I think it was something like 10% faster for copying 1.5GB worth of data off of a mounted volume. What's really interesting is that for a readonly filesystem, the NFS implementation currently seems to cache the data that it receives from the NFS server. This results in extremely fast transfers after the first transfer has occurred. This may be true for read/write filesystems as well (with files that haven't been altered), but we haven't tried that.
The performance _may_ be a little bit worse for a bunch of smaller reads and writes because of the overhead of handling the NFS arguments, but this may be comparable to what MacFUSE does (I haven't really looked at how MacFUSE sends messages from the kext to the process).
A lot of the performance will depend on the underlying backing of your filesystem. Certain things were slow for us, so we cache the results of the stat (which is done frequently) and the open file handle for read/write operations (to avoid expensive operations from the backing store). We only do this for the current file that's being worked on (since KFS doesn't handle parallel operations anyway), and that provided a lot of performance increase. This is really application specific, though. MacFUSE does a good job abstracting a bit of this by allowing you to have some sort of context attached to open files, and this would be something to consider in KFS (either in the C API or in an Obj-C API).
I've heard of ExpanDrive before, but I haven't used it. From what I've read about it, I think KFS would be a perfect fit to get it into the Mac App Store.
Hope that helps. Let me know if you have any additional questions. I've tried to document the main kfslib.h header file, but I'm sure you may have questions if you start working with it.
Cheers,
Whitney Young
FadingRed
wby...@fadingred.com
www.fadingred.com