it says Opera isnt supported, then in Firefox it says im on 64bit and i need 32bit.

so gears is fail already, quite literally. but yeah, it basically dangles a few carrots to devs in a couple ways it works around things that browsers are fixing the right way, that is built-in, via WHATWG/OpenWeb/W3C/etc APIs

as for your data. the way id do it is a GET http://geolocatesomehwere.net/searchstring Accept: application/json;text/html and getCurrentLocation() would wrap this GET. no fancy libs needed. i dont know which geolocate services understand webarch, or dont require an annoying API key though. google cut me off after liek 500 geolocates last i tried, which was a couple years ago before they had an API and i was using perl..

as for the storage, i guess Microformats or RDFa makes too much sense. caching it locally in storage corresponding to the URI of the resource. yeah go crazy with your weird gears shit!

I agree that with a custom API you have much more flexibility in terms of deciding how “simple” (or name any desirable property) you can be, because you’re not bound by the constraints of a DOM model. On the other hand, by reusing the DOM you get a lot for free including events (as mentioned), selectors, and integration with other 3rd party DOM JS libraries, as well as the aforementioned lower barrier to entry for developers.

As you mention simplicity though, I would also add that I believe that simplicity for Gears as a whole should also be a concern, rather than just the simplicity of each gear. I believe a DOM based approach would be a *big* winner here, because the common model reduces variability. Inevitably too, there will be requirements for gears to work with each other, and again I think the common model is exactly what is needed. That’s not to say that the DOM will be able to meet all inter-gear requirements, but I think what’s there is pretty general. Extending the DOM itself is an option in that case too.

Thanks for explaining further. That makes more sense, and is an interesting idea…. having documents that an API can pull up and manipulate like this.

I still think that I personally prefer just having a simple JavaScript API that says “give me the current location” and such, rather than working with the DOM, but I do see how it is interesting.

What I’m proposing is that there be more than one “document in question”.

Currently, as you know, the common case is that a Javscript developer has access to a single document – window.document – and they can use the DOM API on it. I’m not suggesting changing that at all, nor adding any information to that document. I’m just suggesting that we give that same developer a reference to an *additional* locally resident document which encapsulates client-side data and data-oriented services.

It’s like the /proc pseudo filesystem on Linux.

We definitely do try to reuse as much as what we can as possible. This is why we provide small little components that try to do one thing well, that developers can’t do yet. We aren’t trying to provide a separate platform, rather you do your usual Web app, and you have access to a few new APIs.

With the location API, as we work with it in real-world cases, we have found that people like to have a JavaScript API that can just make a programmatic call when they need location information. That being said, you *could* store results in the DOM and have an interval that keeps it up to date. The JavaScript API is there for you to build on.

Also, this data isn’t related to the document in question, but relates to the users browser geolocation, so I don’t see it as a good fit personally.

Cheers,

Dion Almaer
Gears Team