One file to rule them all!

One file to rule them all!

I've just read Q&A about Opera Show. Important advantages of Opera Show are supposed to be small size and whole presentation in one file.

I think that current solution does not provide this.

Data URL encoding makes embedded files significantly larger and whole file becomes tricky to edit, because text editors rarely can cope with file having 100,000 chars per line => not efficient, not usable.


Real advantage would be to support loading and saving pages directly from zip files.

This would be more compatible and portable replacement to mht format - wished many times in this forum.

Zip is quite common and standard format these days, and Opera already reads zip files.

This would enable Opera to have one-file, one-click presentations in independent and open format, which really is smaller than other presentation formats, and this would overcome all quirks and limits of one HTML file.

If zip compression code is too much burden for Opera, it could save uncompressed zip files - they still would be smaller than html+data url and users could [re]compress them with other tools when neccessary.


Please, please, please.

Seems I made that suggestion myself at one time ...

If we keep repeating maybe someone will listen

Originally posted by sgunhouse
Seems I made that suggestion myself at one time ...

Yeah, I did myself too, some significant time ago already. No results till now. Let's keep on asking..
But really, isn't it obvious it's a really handy option, so Opera team shouldn't hesitate, waiting for more votes..? :Psmurf:

Count me in.

The zip file could have a different extension besides .zip so it can be associated with Opera without messing with the .zip file association. A while back, I suggested .owp (opera web page) as the extension. At the time at least, owp wasn't used for anything.

Winamp has .wsz files and Firefox has .xpi, which are basically zip files.

I think it makes more sense to support mht and to support their compression into a "mhz" file.

In particular, zip lacks a "main file", something that MHT has by necessity.

- Joel

And MHT (Mime HTML) is a web standard, ZIP is not.

zip is more widespread, has more tools available and zip reading is already implemented in Opera.

support for zipped webpages could be developed at minimal cost.

zip is already free, portalbe "standard". It doesn't have to have its own rfc.

either format would be great feature for operashow and useful for some other users.

I support MHT for saving entire Web sites, but the one-HTML-file solution used by the Opera Show Generator is great! You can open it in any browser supporting embedded data, and be able to view the presentation.

Not that I've tried, but how easy is it to edit a presentation when it's embedded into a MHT file along with lots of images and CSS? Doubtfully easy. ZIP is by far easier, although it creates an unnecessary hurlde of opening the ZIP and extracting the XHTML file. Using a proper editor, the current solution of the OSG is not a problem. Vim, for example, easily copes with files of more than 100KB. Just use ":set nowrap" to make the images appear on one line, and it's as easy as editing a totally ordinary HTML file (yes, I've just made a quite graphics-heavy presentation with Vim based on a file generated by OSG).

Also, this has nothing to do with Opera per se if I understand you correctly, and should be posted in the MyOpera Community topic.

You can open it in any browser supporting embedded data
= with any Opera 7.5

Using a proper editor, the current solution of the OSG is not a problem.
loooong lines are weak point of most editors. any word wrapping will damage embedded files.
editing and saving whole uncompressed and extra inflated presentation with every xhtml change is more hurdle than extracting it from a zip file, i think.

The column limit for text editors is a big deal.

That's why I use Edit Plus. Its column limit is greater than a million. I've never been able to reach the limit.

UltraEdit's limit I think is only 20000.

Most editors are less than that.

As for mht, I'm not found of it. It's just an .eml file, more or less. Everything is embedded in one file and the embedding modifies the source. To unembed the contents you would have to view the mht file and save as with images, but since the source is modified when you embed, you won't get the original.

I would prefer a format like this for opera. (extension owp or mhz or ....)

file.zip
    index.dat
    file.html
    1.jpg
    2.jpg
    jsfiles
        menu.js

index.dat would just contain one line that tells opera, what file to load.

index="file.html"

If index.dat points to a file not in the archive, Opera could say "file.html not found in archive".

Also, index.dat would not be able to point to executables and there should possibly be some way to check the html file to make sure it's actually an html file.

(Wouldn't want people slipping in viruses in there and having them execute)

Opera could extract the archive to the cache, but I'm not sure if that would be good or not.

Doing everything that way would allow the html code to be whatever version etc because the files would just be bundled instead of being modified and embedded into one file.

I think it would be less work for the devs to implement zip archive save and handling than full mht support.

edit:

Or instead of index.dat, make sure the html/xhtml/xml file is index.ext

If I want to archive web pages, I just "save as + images" and zip them up. Then I just double-click on the zip file, which loads in winrar. Then I can click on the html file inside the archive and winrar will extract to %USERNAME%\LOCALS~1\Temp/Rar$EX<some unique number> and then it will load in Opera. (winrar automatically extracts all other files just in case the html file needs them. Howevever, only works if the web page has a .html extension)

If that could just be a little more automated, that would be great.

I dont like index.dat idea - it introduces new custom format.

IMO it is not needed, Opera could look for files matching Accept header and MIME settings, maybe having hardcoded first choice of index.[x]htm[l] (for reliability and security).

O.K. Just throwing up ideas.

change its name to index.ini and it's not a new format =P

How about changing name of html file always to index.html during saving the page in zip? Upon opening, always index.html would be loaded. Simple as that!

If index.html does not exist (archive with html file/s not saved with Opera) or even if it exists but there are more html files in the archive, a dialog could appear:

"No/multiple matching html files, please choose which one should be opened"

(and a list of files would be available - to pick one and open it)

SIMPLE, Flawless & BRILLIANT as for me!!

I had thought the same, but still couldn't bother stating it...

I have wondered for a long time why there hasn't been any standard form of website-archive where people download one compressed archive containing all the files to navigate through a web site, and then the browser opens some start page within it and the user navigates instantly. I don't know how it would be referred to in url, though: http://......./file.sitezip:index.html

This is the advantage of the zip over the mhz: it allows multiple web pages to be linked.

- Joel

Originally posted by Nasty
How about changing name of html file always to index.html during saving the page in zip?

That would be cool, except if it's an xhtml file or xml file then it should save as index.xhtml and index.xml.

Here's a working example for WinXP at least of what I'm suggesting Opera coudl do (for the loading part).

The zip file includes an archive to test with and readme.txt will hopefully explain.

If I can do that, then the devs can surely and easily make something work.

(just remember. It's just an example).

@moo:
Loading files from inside zip on the web is not a good idea. Zip is not seekable, which means that whole website would have to be downloaded before reading any file. HTTP has its own compression.


URLs?

simple as that,

or maybe if there are any security/implementation problems I've missed, it might be similar to mail attachements:
archive:/some_cache_id/index.html

yeah, fair enough...

Burnout, re your working example readme: "mht.exe is just a quick, rough, dirty and unelegant program." ... but at least you put your braces in the right place. =P

Originally posted by burnout426
Here's a working example for WinXP at least of what I'm suggesting Opera coudl do (for the loading part).

burnout, I don't like the idea - why complicate so much? Doesn't my solution contain everything? I don't see any benefits of your proposal over mine.
Just asking to move on to conclusions.

Nasty, it forgets the fact that people don't always have the extension .html on their files. For one reason or another. Furthermore, if a format were to become popularly supported by web browsers that did not have the extension html, this feature would then be made redundant.

- Joel

Originally posted by moo
Nasty, it forgets the fact that people don't always have the extension .html on their files. For one reason or another.

But what't the problem with it? Original html file name is also being lost. And.. so what? Let it be saved always as index.html.

Originally posted by moo
Furthermore, if a format were to become popularly supported by web browsers that did not have the extension html, this feature would then be made redundant.

"extentension html"? I don't understand what you mean.

extension is what the thing after the . in a filename is called.

Originally posted by moo
extension is what the thing after the . in a filename is called.

I know, but I don't understand what you mean by "supported by web browsers that did not have the extension html" and why would it become redundant.

@moo: it's easy to find start file, but missing or invalid index.ini would make archive useless.

Browser may search root zip directory for index + whatever extension is preferred (using same settings as for HTTP). That would be future-compatible and user-configurable (by MIME prefs: extensions).

In worst case authors may add index.html that redirects to required file or leave only one file in root directory (moving everything to subfolders).

Even if it is absolutely required to point start file zip comment may be better for this (rar uses it for sfx).

Originally posted by porneL
@moo: it's easy to find start file, but missing or invalid index.ini would make archive useless.

Browser may search root zip directory for index + whatever extension is preferred (using same settings as for HTTP). That would be future-compatible and user-configurable (by MIME prefs: extensions).

Agreed. index.ini and stuff is much more a hassle, harder to handle, much more fault-prone and already incompatible with anything - a new file standard instead of just normal .zip with files in it.

When trying to think about how web servers handle choosing the default file, I guess that makes more sense: have as an opera setting a list of files to try first.

Either way, it's somewhat a futile debate =P

- Joel

Originally posted by moo
Burnout, re your working example readme: "mht.exe is just a quick, rough, dirty and unelegant program." ... but at least you put your braces in the right place. =P

Yeh, the index.ini was just something to play with. I agree, that's not the best way.

I too would like to have something like

DirectoryIndex index.html index.htm index.xhtml index.xht index.xml

Here's a newer version. (modified readme.txt to explain and include a couple more example owp files)

Got rid of index.ini and it now automatically handles

index.html
index.htm
index.xhtml
index.xhtm
index.xht
index.xml

The app searches for each one starting at the top of that list, so if both index.xhtml and index.xml were in the archive, index.xhtml would be loaded.

Again, if I can at least get that far with crappy system() calls and crappy code, then the devs should be able work out something for us Opera users (with zip files though and not rar files like I used).

Edit: Cleaned up the code a bit and reuploaded.

@burnout426: not to mention that your solution is browser independent, and probably portable.

If Opera implements it - you'll get two independent implementations and you can call it a standard ;D

lol!

Originally posted by burnout426
Here's a newer version. (modified readme.txt to explain and include a couple more example owp files)

Got rid of index.ini and it now automatically handles

index.html
index.htm
index.xhtml
index.xhtm
index.xht
index.xml

The app searches for each one starting at the top of that list, so if both index.xhtml and index.xml were in the archive, index.xhtml would be loaded.

Now it's wonderful! Perfect!
design team - Nasty, porneL; implementation, coding - burnout426

Now, could someone from Opera Software say only that our initiative has been noticed? Only the fact that you know, nothing more. Please.

Would it be even better to load all supported index files in the archive?

For example, say if I make an archive with both index.html and index.xhtml, would it be better if both pages could be loaded when loading the archive instead of picking the file with an extension of highest priority?

Using my example, code-wise, it would be a simple change to support that.

I do not see much use for that support if Opera created the archive (when and if it could) because there would just be one index file, but if you manually created an archive there may be a reason why you would want to add a 2nd index file; like if you wanted to have an html version and an xhtml version of the same index page.

I don't see too much use for it, but figured I'd bring it up.

BTW, if you check out the Mozilla Archive Format extension you can see how they do it.

Rename the .xpi file to .zip and extract to see the contents. (see scripts directory)

Besides saving to mht, you can save as a zip archive. (uses info-zip's zip.exe and unzip.exe). They do the index.ini deal, except they use an index.rdf file that contains the info about the name of the index file etc.

As for the mht part, looking at nsMafMhtEncoder.js and nsMafMhtDecoder.js in the components dir may help and give a clue on how to save as mht.

Originally posted by burnout426
Besides saving to mht, you can save as a zip archive. (uses info-zip's zip.exe and unzip.exe). They do the index.ini deal, except they use an index.rdf file that contains the info about the name of the index file etc.

As for the mht part, looking at nsMafMhtEncoder.js and nsMafMhtDecoder.js in the components dir may help and give a clue on how to save as mht.

Yeah, .mht seems to be documented so coding saving to it shouldn't be a problem.

Regarding Mozilla archive - they have the index.ini but it seems to be overkill for what we need when just saving to .zip archive.
I also do not see any reason for opening multiple .index.htm/hmtl files when more than one exist - picking one or automatic choosing the one with higher priority would be better.

^^

O.K.

I made a zip version.

It's the same thing as the winrar version except it handles .owp files in zip format instead of rar format and the unzip utility is included.

In getting familiar with python, here's a python version to play with.

It's a lot simpler to setup (if you already have python). It's a smaller download and a lot simpler to modify since you just edit the script instead of recompling. Getting the absolute path to unzip.exe is easier with python and therefore, no environment variable has to be set with this version.

I'll probably base a newer c++ version on that code.

I still think that it would be great if the 'save as with images' function could pass the location of the saved files to an external program. Then, external programs could be made to do whatever with the files, which could include saving as all kinds of formats.

Since the loading of the archives is already possible, it's the saving that needs to be done first. (of course complete handling is desired)

@burnout426: You've repeated your programming mistake. Don't make programs code-driven, but data-driven. Don't repeat code testing presence of each file, but make an array of filenames and process it in a loop.

^^

I do have a c++ version setup like that. I just haven't done much testing with it.

Thanks.

All those old examples from my old site are in this zip file now.