views:

6300

answers:

6

I've been looking at the DropBox Mac client and I'm currently researching implementing a similar interface for a different service.

How exactly do they interface with finder like this? I highly doubt these objects represented in the folder are actual documents downloaded on every load? They must dynamically download as they are needed. So how can you display these items in finder without having actual file system objects?

Does anyone know how this is achieved in Mac OS X?

Or any pointer's to Apple API's or other open source projects that have a similar integration with finder?

+5  A: 

Two suggestions:

The former will allow you to write an app that appears as a filesystem and does all the right things; the latter will allow you move everything server-side and let the user just mount your service as a file share.

Jim Puls
MacFUSE is exactly what I need. I had totally forgotten about it. Thanks man.
Brian Gianforcaro
+17  A: 

Dropbox is not powered by either MacFUSE or WebDAV, although those might be perfectly fine solutions for what you're trying to accomplish.

If it were powered by those things, it wouldn't work when you weren't connected, as both of those rely on the server to store the actual information and Dropbox does not. If I quit Dropbox (done via the menu item) and disconnect from the net, I can still use the files. That's because the files are actually stored here on my hard drive.

It also means that the files don't need to be "downloaded on every load," since they are actually stored on my machine here. Instead, only the deltas are sent over the wire, and the Dropbox application (running in the background) patches the files appropriately. Going the other way, the Dropbox application watches for the files in the Dropbox folder, and when they change, it sends the appropriate deltas to the server, which propagates them to any other clients.

This setup has some decided advantages: it works when offline, it is an order of magnitude faster, and it is transparent to other apps, since they just see files on the disk. However, I have no idea how it deals with merge conflicts (which could easily arise with one or more clients offline), which are not an issue if the server is the only copy and every edit changes that central copy.

Where Dropbox really shines is that they have an additional trick that badges the items in the Dropbox folder with their current sync status. But that's not what you're asking about here.

As far as the question at hand, you should definitely look into MacFUSE and WebDAV, which might be perfect solutions to your problem. But the Dropbox way of doing things, with a background application changing actual files on the disk, might be a better tradeoff.

TALlama
Regarding conflicts, Dropbox apparently won't (ever) [attempt to merge changes](https://www.dropbox.com/help/36). Instead it'll create two file.
mjs
+5  A: 

Dropbox is likely using FSEvents to watch for changes to the file system. It's a great API and can even bundle up changes that happened while your app was not running. It's the same API that Spotlight uses. The menubar app likely does the actual observing itself (since restarting it can fix uploads being hung, for instance).

There's no way they're using MacFUSE, as that would require installing the MacFUSE kernel extension to make Dropbox work, and since I definitely didn't install it, I highly doubt they're using it.

Colin Barrett
+2  A: 

To me it feels like a heavily modified revision control system. It has all the features: updates files based on deltas, options to recover or restore old revisions of files. It almost feels like they are using git (GitFS?), or some filesystem they designed.

rem7
+4  A: 

Dropbox uses subversion and RSync internally to manage revision control etc. Also S3 is the server side storage medium, similar to Syncplicity. I'm a big fan of Dropbox, just wish they'd release a web api already!

Daniel OCallaghan
Yeah you could ge thte same effect by having SVN auto commit and auto update
mcintyre321
A: 

Dropbox on the client is written in python. The client seems to use a sqlite3 database to index files. I suppose Dropobox split a file in chunks, to reduce bandwith usage. By the way, it two people has the same file, even if they do not know each other, the server can optimize and avoid to trasnfer the file more times, only copying it on the server side

daitangio
It appeared to me that if two people have the same file, then it's not uploaded the second time. However, this must mean that files are not encrypted on the client, but the Dropbox documentation suggests that it is. What is your reason for thinking that only one copy of the same file is ever saved on Dropbox's servers?
mjs