I'd like to 'second' this request. We're looking implementing web- based annotation of pages containing escience data and metadata. One of our options is to implement the annotation functionality as a plugin (like annozilla), but we have the problem that we need to support all popular web browsers. To do this, we need to implement as much as possible of the functionality in a platform independent way.
-- Steve On Sep 6, 2:56 pm, Bob Oliver Bigellow XLII <[EMAIL PROTECTED]> wrote: > Well, the way I would see it is this... for a browserplugin/API > mechanism... it could have its own walled garden, so to speak... and > each add-on would be the equivalent of its own "site"... with its own > database, etc, etc... but theseplugin/API "sites" would be sandboxed > on their own like any other... they would not have access to the > database or content of any other site. All it would be capable of > doing it responding to browser-specific actions (clicking a button, > for instance)... or could gain access to the incoming HTML (to give it > time to change it on-the-fly, etc...) > > Then, when you install an add-on into this sandbox... you would have > to give it explicit permission for certain capabilities (like being > able to report back to a mothership site, for instance). > > So, for instance, let's say I wanted to make my own auto-map add-on > that automatically converts addresses on websites into Google Maps > links. I would write the code (having access to its own SQL Lite > storage space and other locally stored static content)... then make it > available to users who have Google Gears installed on any browser. An > IE user on a PC, a Firefox user on a Mac, Chrome user on Linux (when > available) could all use my add-on. By finding the add-on in a > directory, then installing... all incoming HTML could be passed > through my add-on, allowing me to look for addresses and auto-link > them. Also, for Chrome, this add-on would run as its own process (the > way Chrome works)... so IF it slows things down, they will know who to > blame (my add-on will be shown to be the culprit in the Task Manager > of Chrome). Since the add-on cannot communicate with any other site's > databases or content (except through the straight HTML passing through > the browser engine) and no sites can communicate directly with my add- > on (again, except through the passive activity of the HTML passing > through the browser engine)... it would not represent a problem in > terms of security, nor would it break the current security model of > Gears. In fact, it would continue to use the existing security model > of Gears. > > The idea wouldn't be for an add-on to be used for file system access, > for instance. It would just be for adding custom buttons, integrating > with certain services, etc... For instance, someone could write an > add-on that synchronizes their Google Bookmarks with the built-in > bookmarks of the browser... or someone could re-create Google Browser > Sync (which used to be available for Firefox) to be used within any > Gears-enabled browser... or someone could implement an automatic form > filler... with the profile information being stored in that add-on's > local db storage space... which could also optionally be synchronized > with an online service, so that your form information also follows you > from browser to browser... etc... the possibilities would be endless, > but the system would still remain secure. > > On Sep 4, 11:03 pm, Wiolowan <[EMAIL PROTECTED]> wrote: > > > Hello, Bob. > > I also first suggested something like that, as common folders, common > > "public" databases. > > However Aaron explained that such tool as workers enables separate > > Gears applications cross-talk. > > To make your site's Gears stuff be available from other sites you just > > should provide a script that has a worker inside, providing functional > > interface to other origins. > > However you cannot make something that surpasses the general Gears > > abilities. As access to local file system etc. > > I guess that it is possible to make Gears sites into cross-talking > > peer-to-peer network > > For example, if you make a Gears extension (that is, a site with Gears > > lib, and with a "public interface" worker-script(s)) for reading some > > RSS, and I make an on/offline Chinese-English dictionary database, > > then third-party sites may access your reader and my dictionary. > > So, in a way, our Gears systems are "extensions". > > > Gears is restricted by safety constraints. If your scripts and my > > database are in public folder, and/or everybody may access local > > files, then it is easy to drop my table and delete your script files, > > as well as examine the content of /My Documents/ folder...
