On 11/26/06, Phil McCluskey <philmc@...> wrote:
>
>
>
>
>
>
> The mozilla extension archive (.xpi), which is also a zip file, is probably another useful model for what you're proposing.

Excellent. Let's see what we can learn from that.

(From http://www.orablogs.com/duffblog/archives/000536.html)
...
An XPI file is just a normal zip file with files organized in a
special way. Our XPI file should contain the following structure:

helloworld.xpi
+- install.rdf
+- chrome/
+- helloworld.jar

helloworld.jar is another zip file containing all the files we created
in the content directory:

helloworld.jar
+- content/
+- contents.rdf
+- helloworld-Overlay.xul
...

Observations:
- using directory structure as a protocol element is a time-honored approach.
- XPI separates out the install and runtime portions of the package.
- XPI gives the installer first-class status.

One other thought -- I can easily imagine a music package being XPI
itself, since XPI can have data files (for the media), chrome (for the
presentation), and an installer.

> The other question that occurs to me reading through this thread is if there would be added flexibility in allowing optional pointers to external resources, like album artwork and lyrics (or in some cases the audio files themselves), in addition to having them be directly available as contents in the zip/package. This has the advantage of providing a lot of flexibility in packaging a collection, and the potential disadvantage that sometimes these materials won't be available because they've been moved or deleted, or a server is unavailable.

So there would be a blend of static/local and dynamic/network
resources? Hm. For example a song file would be static, concert
listings would be dynamic... That makes total sense.

-Lucas