offline cache discussion with campd

[ 2:20 am] <brahmana> hi all,
[ 2:20 am] <brahmana> Looks like my earlier question about offline cache got lost here...
[ 2:21 am] <brahmana> I read the HTML 5 spec and understood that the cache will be versioned and hence multiple versions of the same cached element will be present on the client's disk. Is that so?
[ 2:22 am] <campd> yeah
[ 2:22 am] <campd> as of 3.1
[ 2:22 am] <campd> in 3.0, there's only one version
[ 2:23 am] <brahmana> ok..
[ 2:23 am] <campd> brahmana: though they won't stick around long
[ 2:23 am] <brahmana> ok..
[ 2:23 am] <campd> brahmana: when you visit a page, it'll download a new version. Once any page using he old version is navigated away from, it is cleaned up
[ 2:25 am] <brahmana> campd, So everytime the user goes online and visits a website which has offline cache, the cache is refreshed provided no page is using the old cache.
[ 2:26 am] <campd> brahmana: sorta
[ 2:26 am] <campd> brahmana: every time they visit an offline cached website
[ 2:26 am] <campd> brahmana: it will check for a new version of the cache manifest
[ 2:26 am] <brahmana> ok..
[ 2:27 am] <campd> brahmana: if there's a new manifest, a new version of the cache will be created and fetched
[ 2:27 am] <brahmana> campd, ok.. answers my question fully..
[ 2:27 am] <campd> cool
[ 2:27 am] <brahmana> campd, However I have another question..
[ 2:27 am] <campd> ok
[ 2:28 am] <brahmana> Now is this cache application specific? As in if a image with the same src is referenced by two websites, the image will be cached separately for each webapp?
[ 2:28 am] <campd> yes.
[ 2:29 am] <brahmana> ok..
[ 2:30 am] <brahmana> campd, Will this offline cache in anyway affect the regular browsing when the user is online?
[ 2:30 am] <campd> if they're online, browsing an offline app, it will be loaded from the cache first
[ 2:30 am] <campd> it won't affect online browsing of non-offline pages
[ 2:31 am] <brahmana> ok..
[ 2:31 am] <campd> so if http://www.foo.com/offline.html is an offline app that references http://www.bar.com/another.html
[ 2:31 am] <campd> going to http://www.bar.com/another.html will NOT load it from the offline cache
[ 2:31 am] <campd> but going to http://www.foo.com/offline.html WILL be loaded from the offline cache
[ 2:32 am] <brahmana> okay..
[ 2:33 am] <brahmana> campd, Regarding the local storage, Can it be looked at as an extended form of what currently is cookie?
[ 2:34 am] <campd> kinda, yeah
[ 2:34 am] <brahmana> Is there any limit on the amount of data that each web-app gets on this local storage?
[ 2:35 am] <campd> yep
[ 2:35 am] <brahmana> Because the spec says that the web-app can use this to store user created _documents_
[ 2:35 am] <campd> 5 megs for the etld+1
[ 2:35 am] <campd> if the domain has the offline-app permission it gets more, but I forget the exact number
[ 2:35 am] <mconnor> campd: is that right? I thought I remembered some wacky combination thing
[ 2:36 am] <brahmana> oh.. ok.. thats pretty big space..
[ 2:36 am] <campd> (which I assume is the wacky combination mconnor's referring to ;))
[ 2:36 am] <mconnor> no
[ 2:36 am] <mconnor> it was something like "foo.bar.com can have 3 MB, and bar.com can have 2 MB" or something
[ 2:36 am] <mconnor> in whatever combination
[ 2:37 am] <mconnor> maybe that was the spec that got deprecated?
[ 2:37 am] <campd> I think right now it's just "5 for the whole etld"
[ 2:37 am] <campd> err, etld+1

Building and embedding spiderMonkey

If you already do not know, SpiderMonkey is the JavaScript engine of the Mozilla web browser. The interesting part about this JS engine is that you can use it in your application and execute JS from your application. Well I can talk a lot about the uses and the advantages of such an embeddable JS engine but thats for another post. Here I will tell you how to build SpiderMonkey and how to embed it in your application and finally how to get your application running with the JS engine.

Actually the first two steps are very well explained in these MDC pages:

http://developer.mozilla.org/En/Building_only_SpiderMonkey
http://developer.mozilla.org/en/JavaScript_C_Engine_Embedder%27s_Guide

• The first one tells you how to get SpiderMonkey and build it. It involves downloading the source and running "make -f Makefile.ref" and thats the end of the build story. You will have the engine binary, both in the form of a reusable library - dynamic and static and also an ready to use JS-execution shell. The reusable library is named libjs.so(dynamic) or libjs.a(static). The interactive JS-Shell will be an executable named js. More about using the Shell here.

• The second one tells you how to write a simple application using this reusable JS engine library. It also explains you the basic types used in the engine and the general essential terminologies. There is a boilerplate program also which you can use to test your first embedding attempt.

With all this great documentation, I was stuck at the point where I have to compile my application with the JS library. After the build I do not get any directory named "sdk" or something similar. It just gives me a build directory with a static library, a dynamic library and an executable. There are also a bunch of object files (.o files) but they are not really of much use. Only two .h files are copied to the object directory and that does not involve the main "jsapi.h" file.

As a result you will end up with a hell lot of compilation errors if you just try to build your application. So there are a couple of steps, probably very evident ones, that you need to do before you build your app.

1. Put all the .h files, header files, from the source (src) directory in the include path when building your app. The best way for this would be to create a spidermonkey folder under the includes directory or your app and providing that directory as the include path to the compiler at build time.
2. Copy the libjs.so to the lib directory of your application and pass it as a linker option (-ljs).
3. The various JS script types map to some system types, probably, based on the OS being used and hence they are present under some #ifdef. If you do not define any OS then you will not get defintions for several types and you end up with compilation errors. To avoid this manually define the OS before you include the first file from spiderMonkey (which is typically jsapi.h). Defining is in the usual way: #define XP_UNIX // -- For linux systems.

With this you should be able to build your application and run it. So you now have a program of yours for which input can be JavaScript and it will compile and run that JS and give you the output.

Happy embedding. :-)