Do

Preferences service in Do.Platform needs to be platform independent

Bug #551102 reported by Chris S.
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Do
New
Medium
Chris S.
Do 0.9 "This Space Intentionally Left Blank"

Bug Description

The current Preferences classes in Do.Platform makes some assumptions that don't apply to preferences implementations on other platforms, such as the windows registry. For one, the base preferences service in Do.Platform assumes that the key separator character is "/", where the windows registry uses the "\" character.

Revision history for this message
Chris S. (cszikszoy) wrote :

I should not that this must be fixed before resuming work on a windows port. This was something I specifically had to change in the Do.Platform assembly to get Do working on windows.

Changed in do:
milestone: none → 0.9
assignee: nobody → Chris S. (cszikszoy)
importance: Undecided → Medium
Revision history for this message
David Siegel (djsiegel-deactivatedaccount) wrote : Re: [Bug 551102] Re: Preferences service in Do.Platform needs to be platform independent

Consider keypaths used as abstract representations that just happen to
coincide with the Linux implementation. The Linux interpretation of
these keypaths is the identity function, and the Windows
interpretation maps "/" to "\". This should be handled in the Windows
backend, not changed at the level of the preferences interface.

Revision history for this message
Chris Halse Rogers (raof) wrote : Re: [Bug 551102] Re: Preferences service in Do.Platform needs to be platform independent

On Tue, 2010-03-30 at 09:27 +0000, David Siegel wrote:
> Consider keypaths used as abstract representations that just happen to
> coincide with the Linux implementation. The Linux interpretation of
> these keypaths is the identity function, and the Windows
> interpretation maps "/" to "\". This should be handled in the Windows
> backend, not changed at the level of the preferences interface.
>

That will be fine as long as nothing wants to use '\' in the keypath on
Linux or '/' in the keypath on Windows, which seems like a reasonable
assumption.

I wouldn't object to a path-component based interface - which would
basically be to pass in (string[] keypath) rather than (string keypath).
I don't think it's particularly necessary, though. I don't see a
problem with David's solution.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.