[OPEN-ILS-DEV] Building/installing Everygreen (Open ILS) staff client under CentOS 5

[Jason Etheridge]

Hey Rick,

> I am not sure when apples vs. oranges might apply to this analogy, but Firefox has been building up their support for apps.  Would it be easier all the way around for you to build an extension/app
> that would be installed within Firefox and then run as an application.  I am thinking along the lines of Prism (formerly WebRunner), which is being integrated to some extent into Firefox 4.

To me, it's mostly a matter of packaging/deployment, since the
underlying technology is Mozilla for all of this.  For Firefox
extensions, there's a little extra code we use to overlay the Tools
menu to give us an entry-point for launching the client.  Firefox can
also be used as a direct replacement for xulrunner, insomuch as you
can invoke an application like this:  firefox -app application.ini

Historically, the client was a Mozilla plugin, and then a Firefox
extension, during initial development.  However, at the time, the
browser was able to self-upgrade itself out from under add-ons, even
if the add-on would be incompatible with the new Mozilla version.
There was also a bias against "web apps" amongst our
librarians/management at the time, so we stuck with xulrunner for
stability and for the appearance of being a normal local application
(the idea was that most upgrades would happen on the server-side
through changes to the remote XUL).

For Prism, presumably we'd just need to create a webapp bundle, though
it might have an expectation for less privileged code than what we're
using.

> Benefits, assuming I understand it correctly, would be the ability to maintain one client that would work across different operating systems, as well as the capability to run offline.

Okay, so we already have client-side code that can run across
different operating systems (it'd be all the stuff in the build/
folder), but the missing link here is the runtime, which has to be
compiled specifically for the operating environment.  This runtime
could be xulrunner, it could be Firefox (which has its own xulrunner
runtime), and it could be Prism (which also has its own xulrunner
runtime).

With xulrunner alone, we have an advantage of being in control of the
exact version of xulrunner used.

With Firefox, we have an advantage in that some Firefox extensions can
help with development/debugging of the client.  Firefox is also widely
deployed.  But as an added layer on top of xulrunner, getting fixes
for certain Firefox bugs may necessitate different versions of the
underlying xul libraries, and that's more opaque to us.  Add-in
plugins/extensions, and it's even scarier to me (though Jetpack will
alleviate much of that, even if the client wouldn't work as a Jetpack
extension).  My Ubuntu version of Firefox breaks patron registration
in the staff client and I have no idea why.  It works with the
Ubuntu-packaged xulrunner.

Prism, that's filling some of the gaps that xulrunner was supposed to
accomplish, and that's managing multiple apps on the same runtime.
Xulrunner can do this, but the presentation/end-user experience isn't
there (this may have changed since I last looked, but I don't think
you can do something like xulrunner -install-app and have it create
app menu options, desktop shortcuts, etc for you).

The staff client already has an offline component, and this doesn't
change with any of these options, and we don't gain any new offline
options using any of these.  My personal inclination is to focus on
xulrunner, since I find it more predictable/grokkable without extra
layers/applications running on top of it.

-- 
Jason Etheridge
 | VP, Tactical Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  jason at esilibrary.com
 | web:  http://www.esilibrary.com