515839 - Better organize location / environment sensor related platform specific bits

Status: RESOLVED INVALID

(Core :: Widget, defect)

Description

[Jim Mathies [:jimm]]

We currently have geo location network level gps and platform specific wifi location code sitting in dom, which really isn't the right place for it. Information provided by hardware should reside in widget and be made available through a set of interfaces there.

We also now have a new accelerometer sensor class in widget for mobile and thinkpads, and we'll likely be implementing support for some of the new win7 location and environment related sensor apis down the road.

Some general rethinking of where this code sits and how it is accessed is needed.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We do have platform specific code in places like netwerk/system and toolkit/system. I propose adding dom/system.

Comment 2

[Jim Mathies [:jimm]]

(In reply to comment #1)
> We do have platform specific code in places like netwerk/system and
> toolkit/system. I propose adding dom/system.

I was wondering about platform apps that are interested in accessing some of this functionality. For example the wifi Geo location stuff that latches directly into system apis on mobile platforms, why would we restrict this to dom related content? Shouldn't I be able to instantiate an object or service that provides access to this information? Maybe I can through dom? I guess I don't understand why it's located there when most of our platform specific code is accessed through interfaces available through widget and xpcom, with helper libraries in places like toolkit.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We actually do want apps to go through the DOM instead of through interfaces in widget/public or whatever. DOM APIs tend to be stable over time, and we don't want to maintain more than one stable interface for the same functionality.

Comment 4

[Jim Mathies [:jimm]]

After a lengthy irc discussion on #gfx, dom/system was agreed upon. The sensor code currently in widget should move to dom, and any new code that isn't related to ui-widgets should go to dom as well. The geolocation code should move to system (it's currently in dom/src/geolocation/code). Platform specific code should be broken down by directory, not swim together in the root. Interfaces should go in dom/interfaces/category/idl, as it is now.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The cross-platform geolocation code should stay where it is --- I think that's what you meant, just clarifying.