I’m the current maintainer of the MAF extension, that provides support for the MAFF format in Firefox. Sull invited me to this thread and I found it really insightful. I may add some more information, and since MAFF is potentially an evolving format, I welcome any input that may help to shape its future.

http://maf.mozdev.org/maff-file-format.html

Sull already provided valuable input, making me think about MAFF as a media packaging format, and the latest MAF 0.15.1provides an interesting feature that’s peculiar to ZIP compression (compared, for instance, to .tar.gz of the KDE war format): OGG files are stored without re-compressing them.

Thanks to this, audio and video in a large MAFF+OGG file are seekable in real-time exactly like a standalone OGG file.

The only strict design goals for MAFF are (1) to be very easy to use and implement, and (2) to be based on existing and widely-used technologies. Backwards compatibility with the existing implementation is also very important.

At present, MAFF archives can be multi-page, but the basic atom is the “page”. Each “page” may be updated or used independently from the others.

Optional metadata (currently stored as RDF/XML) may link each “page” in the archive to an original location (URL) that can be queried for updated versions of the entire “page”, if desired. The root document may link to other resources in the archived “page”, through relative URLs, or to remote URLs, indifferently. All the local resources are “owned” exclusively by the “page”.

If no original location is specified, it currently just means that the file was authored as a standalone package to begin with.

The MAF extension does not support remote MAFF files, at present, but Firefox can access any remote ZIP file using the “jar:” protocol. In this case, I think the caching headers of the MAFF/ZIP file itself are used to check if updated versions of the remote archive exists. That’s different from using the original location in the archive’s metadata to check for updated versions of a “page”.

I hope to have answered some of the questions and not just created confusion :-) I welcome your comments. If you’re interested in MAF and MAFF development, there’s also a mailing list on mozdev.org (it’s used mainly for support questions but it’s also the appropriate place for file format and general inquiries).

Paolo

Bob, I’d love that too. Hand a reader a zip file and say “here it is, you know what to do.”

Luckily, Firefox is very pervasive at this point. Even if you dont use it, its easy enough to install and use when you need to (ie. loading a maff file). And of course, being a ZIP file, you can just extract the files.

What I would also like to explore is building a tool to create MAF files outside of Firefox. I did this when Mozilla Prism came out a few years ago. I created a bookmarklet connected to a little web service that generated Prism WebApps on-the-fly.
This was immediately after Prism was announced so their was no FF integration like their is today. But even with that, I liked the idea of a having a stand-alone Prism browser installed on mac or windows and being able to make Prism WebApps from Safari, Chrome, IE, Opera etc.
The same thing can be achieved with MAF and any other ZIP based archive format.

http://prismspectrum.com/bookmarklet

It would also be nice to open MAFF with a lighter version of FF. Posibly even the mobile browser fennec.
https://wiki.mozilla.org/fennec

Part of my thought about this is that there’s a progressive experience that goes from basic, static, HTML web page *about* a song (or album), to a functional song (or album) experience as a standalone file (say MAFF), to a fully functional song (or album) experience in one’s music library. So, that’s an opposite / positive way of describing graceful degradation.

When there’s a URL on the page in a link, that works in any browser. But, in the awesome player / library, that URL is something special to process with wget, and then (in some cases) to override with a local path to the downloaded file.

So, I would imagine the “format” part to follow a few basic style conventions that can be parsed by the player / library for unique features of the software, like file download or quick summary info popups.

I definitely think the software is the more interesting / challenging thing to work on, mostly because there are so many interactions “beyond-Winamp” that become possible, that can be explored and played with.

But, at a core “engine”-level, the software is maybe just managing a directory of MAFF, extracting data and info from the song / album HTML, maintaining a database of corresponding data / info (e.g., play count, track relationships, my tags, etc.), downloading / uploading / transferring media files, and downloading / uploading / transferring / importing / exporting parts of the library database.

Not super trivial, but I don’t think there’s a big puzzle to the engine — the puzzle is in the new interactions.

For example, I could see a portable media document as a pair consisting of (1) the URL of the top card in the deck, which is an HTML document at the root of the tree and (2) a set of arguments for wget to mirror the page. Then wget is the non-generic software doing the lifting.

I wonder if Firefox can read a MAF file hosted on a web server (i.e., via a non-FILE URL –HTTP, FTP)? Have to try that. If not, that’d be a nice feature to add (feature or add-on) to browsers.

So, part of the idea of a “HTML card” is that, even though one would have to have a player / library to do really cool things, the pure HTML can provide an experience that gracefully degrades, but is still usable in any browser / email program.

With MAF, maybe that fallback is absent in some cases (e.g., where Firefox is not present).

Still, all of this is about introducing new behaviors / scenarios that people embrace, and I can imagine that getting people to unzip MAFFs is not necessarily a huge hurdle.

And, of course, for some of us who use Firefox all the time already, no hurdle!

”
MAFF files are standard ZIP files containing one or more web pages, images, or other downloadable content.

For example, you can save to disk all the open tabs at once in a single MAFF file.
“

In that vision, there would still not be a file-of-files abstraction in web architecture. MAF and similar things would grab this pivot page and whatever they needed to render it in an offline context.