[Sugar-devel] directly browsing compressed content in the datastore

[S Page]

I sent "Viewing compressed content using jar: protocol in Browse !" a
while back, no one cared :-)  To repeat, the XULRunner engine can
directly browse files in JAR and ZIP archives using Sun's jar:
protocol.
Regardless, I've been playing with it some more in 8.2.1.

Once you allow Browse to access the Journal's datastore[*], you can
directly load most HTML content from the downloaded .xo or .xol file
URL in the datastore, *without* ever unpacking/installing the content
at all!
For example,
  jar:file:///home/olpc/.sugar/default/datastore/store/LONG_UUID!/path/to/page.html
(I modified copy-from-journal to determine the LONG_UUID for
downloaded bundles.)

I've tried this with World Digital Library, NET Bible, and Web design
reference.  It Just Works -- CSS, images, links, everything.
Performance seems fine.  It also works with the Help activity, just
view the XO_Introduction.html in the downloaded Help_XO .xo file in
the datastore, *without* ever unpacking it.  I think there's no
conflict with the Sugar team's proposals to merge activities and
collections into http://wiki.sugarlabs.org/go/Unified_Bundles

I think this ability is pretty significant for large local content
collections such as wiki slices or Karma courses on a machine with
limited storage.  Even using a compressed file system, unpacking
something into a second unneeded copy seems a waste.

So what would it take to let content use this capability?  It seems
the bundle's .info file just needs to be able to say "I don't need to
be unpacked" and then contentbundle.py can start Browse using the
existing activity_start path setting, but made relative to the bundle
in the datastore using the jar: protocol.  I filed
http://dev.sugarlabs.org/ticket/1258

[*] The catch in OLPC is Browse can't access /home/olpc/.sugar. its
permission is 700 and I guess Rainbow runs Browse under a different
UID.  You can either chmod 755  ~/.sugar, or disable Rainbow by moving
/etc/olpc-security out of the way.  If Rainbow maintains this
restriction in later Sugar, maybe it can open a hole or symlink to the
bundle in the datastore and hand this to Browse.

As I said before, you can also browse remote ZIP/.xo/.xol archives
using the jar: protocol without unpacking them, if the server gives
them the mime type application/java-archive.  Maybe ASLO should do
this, it's useful.

Regards,
--
=S Page