Is there any roadmap?

No particular road map per se, I take suggestions and requests as they come. Presently in progress is 1.1, which includes the tracker. Resource fork support is not currently planned.

My guess is that they are encoding their mac files in .sit format.

On a Macintosh, there are two forks available for a file to use. Not all files contain a resource fork. Many (like a text document, or a file from a PC using Windows or Linux) have only a data fork. A data fork holds data (like the contents of a text document), while a resource fork holds categorized data for the application itself or application that created the document.

The resource fork is constructed in a similar fashion to a non-relational SQL database. It contains resources (or tables as in the SQL simile) of a specific type that hold a single or multiples of that type of data. Below is an ascii representation:

Resource Fork of an application
        |
        +------> Resource type 'vers'
        |                     |
        |                     +------> 'vers' data ID 0
        |                     |
        |                     +------> 'vers' data ID 1
        |                     |
        |                     +------> 'vers' data ID 2
        |
        +------> Resource type 'icl8'
                              |
                              +------> 'icl8' data ID 128
                              |
                              +------> 'icl8' data ID 65534

As shown above, an application can access its own resource fork and obtain the data in the following object oriented fashion (demonstrated in pseudo-code):

getResourceData ( myResourceFork().resource('vers').id(0) );

Whereas in the data fork, one must read in a linear fashion and use byte offset identifiers (or termination characters) to seperate data.

On a Macintosh, the resource fork and data fork are stored on the filesystem as being a single file. You must use the Operating Systems (OS) Application Programming Interface (API) to access the resource fork stored in the file system (HFS/HFS+ on a Macintosh). If you try to store a file that contains a resource fork on any other file system (such as NTFS for WinNT/WinXP/Win2K, FAT32 on Win95/Win98, ext2/ext3/reiserfs/xfs on Linux, or HPFS) the resource fork will be lost because almost all file systems only store data forks. On Macintosh, all files have a data fork, so they are at least compatible with other file systems. However, imagine if an application (which stores it's machine executable code in the data fork) loses its resource fork; it may run, but it will but will not be able to read any resources it has stored in its resource fork). Another boon is that Macintosh has not store executable code in the data fork for over 10 years. Only 68K applications (meant to run on old-world macintoshes with a 68000+ processor from motorola created and popularized before the first G3 chip), Nowadays, the executable code is stored in the resource fork (PowerPC code).

Apple has realized this as a potential problem and has now moved (in Mac OS X) to the .app architecture created for NeXT (owned by Steve Jobs and the precursor to Mac OS X post Rhapsody). The .app architecture incorporates old resource fork data inside a folder and in data fork files. Given the same ascii representation above, in the .app architecture it would look the same but using files and folders. So the 'icl8' id 0 data would be inside the data fork of a file stored within the .app folder of the application (you can see this by right clicking on a cocoa application and choosing "Show package contents". This also allows Mac OS X to operate on file systems such as UFS (DVD content is stored in this format as well). Wishingly this could mean that Macintosh could some day operate under the same platforms that Windows does.

For now, the only way to safely transfer files with resource forks is to encapsulate both forks into a single data fork (encoding them with Stuffit for example to make a .sit file). Where you can make a single archive like a .sit, which stores all the file data in the resource fork, transfer it over the internet, then require the end-user to decode the archive and restore the original file with both forks. Demonstrating the other benefit of the .app architecture that an application (since it has no resource forks) can be compressed in say, a zip or rar archive (which does not save resource data).

Hope this length explanation has been helpful. Cheers, devin.

Thanks, devinteske! Much appreciated. :D

Did that take a long time to write?

When designing Wired, I did not take resource forks into accounts, because I consider them outdated starting with OSX. Do people still use them? Is resource fork support a show-stopper for you? Let me know.

Regarding .app/.pkg - these bundles are handled like folders in the lower levels of the file system and show up like folders in Wired, which means you can download/upload them like folders.

The problem is, symlinks break, rendering them essentially useless. Carracho actually doesn't have this working 100% correctly; if Wired did, it would be a major draw for people to switch.

Hmmm, thought I had read that somewhere as a new feature of Panther.

Well it's fine to expect Apple Carbon apps to do it that way, but how many people are going to be sharing Apple Carbon apps? Non-Apple Carbon apps however I would hardly expect to do, because why go through the trouble of writing a Carbon application which can run on Mac Classic and Mac OS X and then butcher it (spinning the resource fork off into the data fork) so that it will not work on Mac Classic? The developer might as well have created it in Cocoa.

All you need to do is stuff the file, and wired won't butcher it.

That said, I'd prefer that uploading .apps would work - i.e. privs, symlinks, etc. should all be preserved.

Eeek... do NOT resolve the symlink and download the target, at least not without that being a non-default option. Otherwise, you can think you're downloading a few megs and end up downloading gigabytes instead.

I agree, ownership should NOT be preserved.

Symlinks should be preserved, NOT followed. That way, you preserve the form of what exists on the server. If it's got relative symlinks whose scope is retained within the app bundle, then you're fine. If they go outside the app bundle, then HOPEFULLY they point to something that will exist already on your system. Otherwise it breaks. I think that's a reasonable compromise between inadvertant downloading of lots of random stuff, and breaking applications.

No, symlinks should normally be resolved for uploads and downloads.
However, within an .app bundle, I think it should be treated specially.

Here's a contrived example: A (poorly designed) BBS program, call it UnWired, is an .app bundle, but requires that the .app bundle contain a folder that is the server filesystem. Fortunately, UnWired allows you to use a symlink or alias to this folder, so it can live elsewhere. If you upload a copy of the app, it should NOT resolve the symlink/alias to your whole filebase.

I agree, I've seen very few symlinks within app bundles, but I have seen a few. If the symlink is to something that should normally exist on the system anyways, then resolving the symlink wouldn't be desired behavior.

I don't know... I guess it seems like it should be user-definable behavior, just like with cp (-r vs. -R). Of course, this just gets into one of the major problems with OS X - the existence of both aliases and symlinks, with different behaviors. But I guess I think that uploading/downloading stuff to Wired should behave like a finder copy - preserve the links, don't resolve them. Certainly preserve file mode (not just executable bit, but read and write as well... but probably NOT setuid/setgid... I don't even want to THINK about special files of course) and certainly not file mode.