Things that are closely related: ebooks, the CMX and Cocktail music packaging formats, the offline features of HTML 5, and single page web apps. And maybe Adobe AIR.
Except that epub, the open format of ebooks, usually doesn’t support Javascript.
If I had to bet, I’d put my money on epub. The model of providing a zip file of HTML with an XML manifest is an easy evolutionary step which has been invented independently many times. CMX/Cocktail could easily migrate in that direction.
Epub uses an XML manifest, not something developed under the microformats.org umbrella. My experience with the XML is that it’s a bit cumbersome and could be simplified by using more plain old semantic HTML in its place. But whether a microformat.org production is more useful than plain old XML is a different question.
This is a topic I’ve been thinking about / playing with a lot lately, but I’ve been focused more on the idea of the player / library that plays / manage the “manifests.”
I am sure there’s value in the idea of a zip-like format, with a manifest, that can be used in a variety of ways including importing into iTunes-like players / libraries. But, if you have a new kind of player / library first, then there is one really interesting thing, I think:
The manifest doesn’t have to come in the same package as the binary files (so, I think of it more as a “card” that you can send around). The “card” can be a fundamental, very portable, medium–that is specifically web-like–specifically a web page–that is really easy to give to people and share for free.
Functionally, the “card” player / library has to be a resolver / downloader / streamer of the file (URL) references in the “card.”
And I think that the “card” player / library could work well as, itself, a web app (desktop or on the WWW) that plays / manages these special media web pages. Then the whole library is essentially a sharable web page, the music format is essentially a shareable web page, and the player / library does the resolving / downloading / file management behind the scenes.
(Also, the whole player / library / media format becomes skinable /extendable via HTML, CSS and Javascript. . .)
What do you think?
I know Lucas is aware of this already but I wanted to mention it again…
MAFF is maing a comeback.
http://maf.mozdev.org/
Paolo, the current developer, has been doing a great job. I talked to him about supporting HTML5 video and audio elements so that the saved archive file would include the media as well.
MAF is also ZIP based and RDF/XML.
“Information about the archived files is stored using RDF, an XML format particularly suited to describe metadata about web resources. The matadata is stored using a special MAF XML namespace.
I’ve talked to Paolo about how I envision using this format, basically similar to what Jay has said in his comment. For example, HTML5 “Video Games” and other experimental interactive media can be distributed as MAF Files. If a mobile device could handle the format, it could be a very interesting rich media player… XSPF playlists of MAF Files ;)
etc etc.
I am done with Adobe Air as an interest of mine. I just like the feel of Air apps. Some are better than others but overall, I’m just not interested in that technology.
I am familiar with epub and plan to look into more. I basically got into MAF and havent looked back.
Not familiar with CMX or Cocktail but honestly I am jaded by the companies behind them so they are not too interesting to me either.
I like MAFF+OGG right now. I wonder what a Google Chrome[OS] equivalent would be.
Sull
note: “I just like the feel of Air apps” should have been “I just DONT like the feel of Air apps”
About MAF, I wonder what the REST POV would be.
It’s a snapshot of a set of representations. It’s not the resource itself. The disposition is related to caching headers. The objects in the snapshot are specified by links in a hypertext document which is the master file.
Jay, how does a “card” differ from the top-level HTML document in a MAF file, except that it can move around independently?
Right — it can move around independently.
To me, the important thing is the player / library that does something with the HTML. I think that “something” would become truly web if the “card” were more independent of the binary media files. But, it maybe doesn’t matter if the player / library makes management of those files disappear, much of the time (the way a web browser makes management of JPGs on websites disappear).
But, as long as media players / libraries are file centric and/or dead-ends of information, they’re counter the revolution.
More copies, more contexts, more inter-linked.
So the key is precisely that it’s not an archive, and the player/library manages caching of leaf resoures per its own convenience?
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.
http://maf.mozdev.org/
”
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.
“
Sounds good — I am starting to see little downside to MAF in these scenarios. Obviously, getting native support for MAF in other browsers and even at the OS level (e.g., click on MAF opens in default browser) would be ideal.
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!
I don’t have a clear picture of what needs to be a new protocol and what is pure software.
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 don’t know if this is getting beyond the scope of what’s good to do in a comment thread–I’d be into brainstorming around this more, if that’s fun / useful.)
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.
I would not count on other browsers supporting .maff although the plugin does also create mhtml which extends its usage to IE and i think a a few other browsers? Ideally, it would be great if MAFF or something like it was a standard across all browsers but I’m guessing that this takes us right down the road of file format control and spec preference. They will advance or create new formats to do what MAFF already does and go into the areas that we are talking about with media packaging. Sony and Apple are already releasing such tech as Lucas mentioned in his post.
Not to mention the name Mozilla Archive Format as being supported by Safari, Chrome, IE? Like everything, there is a game to play.
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
I’d love to see a simple open source software bit of “reader” hardware that lets me take a winzip or .rar of a gutenberg.org book and read it all kindly.
Single-site apps of the kind you get with Fluid are somewhere in the mix here too.
Bob, I’d love that too. Hand a reader a zip file and say “here it is, you know what to do.”
Hello,
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