In LibX 2.0, all code that runs in pages (for autolinking, etc.) is based on LibApps. You can see the LibApps running in your edition by selecting the “LibApps” tab in the Preferences.
It is possible to create your own LibApps via the LibApp Builder. The LibApp builder is a web interface, similar to the edition builder, that allows anyone to create modules, libapps, and packages. It uses a separate sign up than the edition builder, so you have to create a separate account.
To build your own Libapps, you’ll need to learn about packages, libapps, modules, and feeds. The best and most comprehensive documentation we have is Sony Vijay’s MS thesis. Sony is the primary author of the Libapp Builder.
Put briefly, a module is a small piece of JavaScript code that runs in a page. Multiple modules operate together in tandem to perform a function, this is called a LibApp. Packages are collections of LibApps (as well as other packages). Packages, libapps, and modules form a hierarchy – a tree, in CS terminology. Each package, LibApp, or module is describe by a unique URL at which it can be found. Here are some examples:
The LibApp that links ISBNs can be found here. It is really just a description of the modules it contains, for instance, this one. This LibApp is part of a package, which is found here.
The LibApp builder allows you to create, share, modify, and publish package, LibApps, and modules, without needing to understand the internal (XML) format you find in the links above.
What, then, are feeds? Feeds are a vehicle to serve packages, LibApps, and modules. Each of them is stored inside a feed, based on the AtomPub specification. That’s why we refer to them collectively as ‘entries’ (see atom:entry). A feed may contain multiple entries. But note that a package or LibApp may be composed of entries from multiple, different feeds. So for instance, you can create a new LibApp in a new feed you create, but it can refer to (and thus use) modules contained in other feeds (such as the LibX core feed, which we maintain).
To use the LibApp builder, you thus need to create a feed, and at least one package, one LibApp inside the package, and then you can add modules to it. It also includes a search interface so you can include modules others have created. For more information, read Sony’s thesis.
LibApps can be tested right from the LibApp builder. If you have LibX installed, it’ll tell LibX to temporarily download your LibApp code and run it. Once you’re satisfied, you can “publish” it, which freezes it and puts it at its final location.
If you’re an edition maintainer, you can subscribe your users to packages you trust. Since LibApps can do things that are potentially sensitive, we do not offer a search interface for LibApps and package that were created by just anyone (though anyone can create any LibApps), but rather only by users we trust. Nonetheless, as an edition maintainer, you can subscribe your users by specifying the URL of the package you want them to subscribe. Note that you need to specify the package URL, not the location of the feed. For instance, the LibX core feed is at libx.org/libx2/libapps/, but the LibX core feed is at http://libx.org/libx2/libapps/libxcore.
We’d love for people to give it a try.
I’ll close with a small concern of mine. While we believe in the power of LibApps and the opportunities they provide, we are a little concerned that the programming model of packages, LibApps, and modules may be a bit confusing to novices. I do note, however, that it is possible to create single-module LibApps, in which all JavaScript code resides in a single module. These are, in essence, similar to Greasemonkey scripts.
