Talk:Features/Content support: Difference between revisions

← Older edit Newer edit →

@@ Line 57: / Line 57: @@
 #* Offering hints as to the number of updates available for content already stored locally
 #*: <small>(as the current Activity Update interface offers. the default hint should probably be less bold; rather than a page listing the updates in detail and asking you to click "go!")</small>
+== Browse can handle content bundles directly ==
+''The widely-deployed .xol content bundles only have minimal support (they can only be launched from the journal).''
+: Not true, you can view .xol (or any ZIP file) contents in Browse ''without installing or unpacking'' using the jar: protocol ({{bug|1258}}).
+Copy and paste the following into your browse bar , including the "jar:" on the front.
+ jar:http://wiki.laptop.org/images/3/3e/Biology-9.jar!/Biology/index.en.html
+This has some interesting implications.
+* Sugar code doesn't have to keep a .xol and a Library directory in sync, installing and uninstalling the lattr
+* The file system ensures uniqueness of content bundles
+* Instead of making web pages telling readers how great some content is, they can view it for themselves before they download.
+=== Limitations ===
+* Some collections have an index.html that does a meta http-equiv refresh to a path in file:///home/olpc/Library , this won't work (and I think breaks anyway in other Sugar environments)
+* Some collections (Biology, NatureImages, TranslationDictionary) reference a /usr/share/library-common/css/master.css).  This won't work if you browse them remotely.
+* I don't know what the performance implications are.  I know Firefox 3.6 has additional performance boosts as Mozilla moved more files into a single runtime .jar file.