Re: Web Application Packaging Format Requirements: 1st Working Draft Published

Hi,

I was asked to review this document and make comments. I had written  
a reply to Marcos offline which I will also post here... It describes  
our current situation and thinking, as well as why we currently  
package our Widgets the way they are. There is also another twist  
that I realized as I was looking at the section of the documents on  
the MIME types for different Widget formats that I've included below.

> Regarding packaging, I can at the very least say that we support  
> three versions technically, not just the two that are in the  
> document at present. We support a bundle (folder) format, zip  
> format and our new proprietary format. Each format has its  
> advantages and disadvantages. Currently, we consider our  
> proprietary format to be the best and bundles to be the worst for  
> us. We consider aspects such as speed and especially security. For  
> example, we need to make sure Widgets launch quickly, and we also  
> verify their integrity on each launch.
>
> Bundles are nice and easy to implement and deal with, however, they  
> do not provide a double-click solution (unless you are on the Mac,  
> where a folder can appear as a file). They are also difficult to  
> ensure their integrity. We actually don't have any security checks  
> on bundled Widgets, and they are difficult to use on Windows since  
> you can't just double-click them as mentioned.  Because of this bad  
> UI, we don't consider them a real deployment solution on Windows at  
> all. You can test them by running the bundle, but that's about it.
>
> You can do a complex signed manifest solution to ensure integrity  
> of a bundle. You just have a signed manifest which points out the  
> files, which would have their MD5 in the manifest. But that  
> requires potentially a lot of file IO just to check the integrity.  
> Not only should you check the integrity of the files you know, you  
> might want to guard against any mysterious new files appearing in  
> the bundle. I don't consider this a feasible way to deploy a  
> Widget, at least for us, as we want very fast launch times and a  
> security check on each launch.
>
> Zip file format is a convenient way to get a double-clickable  
> package which still allows us to unzip it and use it like a bundle.  
> However, this format seems to trip up some browsers which are  
> intent on recursively unzipping things. Also, the zip format is  
> slow, and our engine needs metadata from the file these days, so  
> unzipping it to get just the metadata can be painful. In fact, it  
> proved to really slow us down in version 3.0 when we started to  
> need the metadata. So we switched to our current proprietary format  
> for 3.1. We don't currently support signed zip archives (IIRC), but  
> we could. But we do an MD5 check on each launch. Since it's one  
> file, it's not so bad performance-wise.
>
> Our proprietary flat-file format allows us to map the file and read  
> everything as if it were memory. This does mean we don't get the  
> same compression as with zip, but since images are always where all  
> the disk space goes, it's not a big deal. Widgets are slightly  
> larger in this format, but the speed of opening and launching them  
> has gone way up since we switched over. These support signing and  
> are again easy to MD5 since it's one file.
>

Now regarding that 'twist': one of the things that's been requested  
of us was to have a one click method of deployment of a Widget. As it  
turns out people don't want to download the engine and then a Widget,  
they just want the Widget. So we have a method of deployment where  
you merely download a small mini-executable with the Widget bundled  
inside. When run, the mini-app checks to see whether you have the  
appropriate version of our engine and if not, it will install it or  
upgrade your current install. Then it opens the Widget. If you  
already have the engine, you just open it and the Widget will launch.  
I'm not sure if that has any place in this discussion, but the point  
about a simple install of a Widget without the user caring about the  
engine I think might be something to ponder.

-- Ed