Again: other browsers (opera/gears)

Hi all, and please forgive me for reviving such an old question. I hope the horse I'm beating has come back to life.

I am having a very hard time deciding to switch from opera to firefox just so I can use zotero. (OTOH, I am regularly doing bibliographic work in the middle of my other, everyday browsing, and had I been using FF/zotero, I would surely have a better overview of the hundreds, no wait, thousands of files I have collected by now.)
Therefore I have been trying to read up on the technical reasons for the exclusive focus on firefox. (Yes, I know that everything still has to be coded by someone, which makes for other problems, but anyway.)

Now I wonder what exactly are the "core functionalities" that are not exposed in Opera and, more exactly, if they either are available now or are/would/will be accessible via google gears.

First, google gears: AFAIU, it is an API infrastructure that many browsers, including Opera [1] and Firefox [2] are supporting or planning to support, and it features a Database API (based on SQLite) [3].
Also, switching gears (no pun intended) in as an intermediate layer might helpopen zotero for even more platforms/deployments (ie, safari/webkit, opera, mobile, android etc.). An on top of that, it's BSD-licensed.

Second, opera specific: In addition to its upcoming gears support, I've found two things for opera widgets [4] that sound like a good fit for some things that zotero probably does: A scraper library [5] and an online XML storage [6].


I have no idea whether it would be possible to completely rely on gears, or do that and spice it up with some of opera's own board weapons, or if that still wouldn't be enough to reproduce the functionality of Zotero. But I've got the impression that there's quite some movement in the browser-API world and maybe enough things have already changed.


Unfortunately I am not a programmer AT ALL, so I can just humbly ask if you think these are or could become interesting perspectives after all. And I'll be very ready to beg/ask/push the opera developers and developing community to do the coding if necessary (that's precisely why I want to get an impression of what would be needed).

Thanks for your patience and for any insight.

Andreas Wagner


[1] http://labs.opera.com/news/2009/02/20/
[2] http://www.builderau.com.au/news/soa/Google-debuts-Gears-for-Firefox-3/0,339028227,339289784,00.htm?feed=pt_gears
[3] http://code.google.com/intl/de/apis/gears/api_database.html
[4] http://dev.opera.com/articles/widgets/
[5] http://dev.opera.com/libraries/scraper/
[6] http://xmlstore.labs.opera.com/start.jsp
  • Now I wonder what exactly are the "core functionalities" that are not exposed in Opera and, more exactly, if they either are available now or are/would/will be accessible via google gears.
    Off the top of my head: full and persistent integration with the browser UI, access to the currently loaded document from site translators, local file I/O with stream and character set support, dragging/dropping text/files to/from the OS, copying content to the clipboard, opening a local socket for word processor integration, observing and rewriting HTTP requests for 1.5's advanced proxy support, observing HTTP responses for automatic RIS/CSL ingestion, gzip support for fast syncing, RDF support for import/export, automatic locale support, external process launching for PDF indexing, an idle observer for running backup and sync operations, flexible attachment opening, revealing files in the filesystem...

    Opera Widgets and/or various HTML 5 API proposals might provide partial support for a few of these things, but nowhere near what's needed to approximate current Zotero functionality.
  • To play devil's advocate, though, and to press both of you:

    The "why don't you recreate Zotero for my browser?" question is tedious, in part b/c it fails to recognize how much work is embodied in Zotero, and how much it stretches even a very rich and flexible platform such as Firefox. Trying to recreate Zotero for a proprietary browser with minimal market share is completely unrealistic.

    OTOH, a lot of what Zotero does could be replicated as loosely-knit services and such.

    Example 1: data storage. I could certainly imagine a lightweight interface in the browser, that could rely on the HTML 5 local storage stuff. But I could also imagine a whole lot of other options.

    Example 2: data scraping. See Alf Eaton's work on refactoring the scrapers to use JQuery, and therefore not be dependent on E4X. See also previous mention of things like bookmarklets.

    Example 3: related to #1, I recently blogged about a really practical problem with formatting of documents that essentially argues CSL processing ought to be off-loaded closer to the document, and standardized.

    None of this is to say it's Zotero's job to do this; just that there should be room for this moving forward.
  • Hi all,

    Just when I had a fine reply to this thread about two-thirds ready, firefox has just crashed on me, so I apologize for this posting not being more elaborate. Sorry also for not getting back earlier.

    Thanks for your replies.
    I realize that my wording in the initial posting made it sound too much like the tedious question Bruce has mentioned. But in fact I do care a lot about open standards and the main thrust of the issue would be to ask if there was a possibility (at least theoratically, for now) to base zotero not only on GPL licensing but also more on Open (Web Application) Standards. Then any browser supporting those would be able to make use of Zotero. (Html5 seems to combine the efforts of W3C and WHATWG, so this would be a good place to start indeed. The numbers in brackets in the list below refer to the sections in http://www.whatwg.org/specs/web-apps/current-work/)

    Taking the list above, I had tried to collect parts of applicable standards, but being too tired now, I cannot reproduce it in all its beauty. Just one caveat: I am not saying any of the items is a sure bet: First I had question marks where I wasn't sure, but when I ended up with question marks everywhere, I removed them again ;)
    But then again, this is anyway just meant to maybe raise your curiosity.


    - full and persistent integration with the browser UI: XBL2
    - local file I/O with stream and character set support: HTML5 Client-side storage (5.11) (Even less sure about character set support)
    - dragging/dropping text/files to/from the OS: HTML5 Drag-and-Drop (6.9)
    - copying content to the clipboard: HTML5 Drag-and-Drop (6.9.6)
    - observing and rewriting HTTP requests for 1.5's advanced proxy support: HTML5 Server-sent Events (7.2)
    - observing HTTP responses for automatic RIS/CSL ingestion: HTML5 Server-sent Events (7.2)
    - opening a local socket for word processor integration: What kind of socket? HTML5 Web Sockets? (7.3)
    - automatic locale support: no? (see 12.1)
    - access to the currently loaded document from site translators: ?

    That still leaves the following for now:
    - gzip support for fast syncing
    - RDF support for import/export
    - external process launching for PDF indexing
    - an idle observer for running backup and sync operations
    - flexible attachment opening
    - revealing files in the filesystem

    I am not researching these (or the former items) further for fear of FF crashing again, but will do so soon.

    Anyway, I suppose I will have to try and have a look at the code and at the specs I have in mind myself. But not being very good at things like these, not having much time for them either and being curious about a few other projects as well (e.g. wikindx4), this will surely take me a while. Non promises then.

    Thanks for your replies again, and maybe you find the issue worth another thought or two.

    Cheers,
    Andreas
  • No, sorry, most of the API sections you link to don't provide the functionality I'm referring to.

    Zotero is a desktop app, with desktop app functionality. It's a desktop app for the same reasons that there are desktop mail clients—or features in browsers beyond rendering engines. The new Web APIs are promising, but they're mostly solving different problems. As Bruce notes, there could certainly be a lightweight, cross-browser web app that used some of these new APIs and interacted with Zotero server data, but that would fundamentally be a different piece of software.
  • Ok. I see. All the more thanks for your reply and for the time it/I took you.

    (I'll try and make up my mind about what "core functionality" in opera it is that I (seemingly) can't live without. I have a bad conscience for not being able to contribute back to your efforts for lack of practice with zotero. About the lightweight web app, I'll possibly see later.)

    All the best,
    Andreas
Sign In or Register to comment.