Re: only use "/" in values, not names..?]

[linda w <cygwin at tlinx dot org>]

Igor Pechtchanski wrote:

> On Thu, 12 Feb 2004, linda w wrote:
>  
>
> > [snip]
> > Speaking of compatibility -- there is only 1 application I know of that
> > uses "/" in keynames -- Cygwin.  Since it's already been noted that this
> > makes it very awkward to access these keys in /proc, perhaps cygwin
> > could op for better windows compatibility and go with the unofficial
> > custom of not using "/" in keynames?  Many or most examples I've seen of
> > manipulating the registry show the use of some "change separator"
> > facility and then use "/" as the example separator in code examples --
> > as "/" is already the separator in other parts of the OS and "\" is a
> > pain to use since most modern languages use it for literalizing the next
> > character
> >
> > What do you think?  Are these fixable/changable?
> >
> > Thanks,
> > -linda
> >    
>
> <PEDANTIC>
> Technically, Cygwin doesn't use "/" in keynames -- it uses it in value
> names.
> </PEDANTIC>
>  
===
   Yeah yeah yeah...and I probably don't cross all my t's either! :-)

> I believe that backward compatibility will preclude any attempts to change
> the mount key names...  Especially with the plans to move the mount
> information out of the registry altogether, the extra effort to change the
> key names now is probably not justified.
>  
----
   ?   If it's moved out of the registry, that's fine, but if it isn't, I'd
have to ask how many apps rely on this functionality and whether or not it
really would break anything.  Certainly moving it out of the registry
entirely would have no less impact on "backward compatibility"...ahem!
Sometimes I get the idea that you are are onery/cantankerous just to be
so, not always for reasons you strongly believe in...as though you like 
to play "devil's advocate", so to speak, just because!  :-)

> I don't see that as much of a problem, though.  Most command-line registry
> manipulating tools (including Cygwin's regtool) provide a way to change
> the key/value separator.  API calls don't care one way or another, as they
> walk through keys as explicit strings, and rarely do parsing.
>
> The only mechanism I can think of that is adversely affected by this
> convention is /proc/registry, because of its attempt to map the registry
> onto a filesystem. 
---
   Attempt?  It seems like a pretty darn good idea/attempt.  What is 
the registry but a hierarchical, typed, filesystem? 
It even needs to be "defragged" like a primitive filesystem.
Often, I wish users could supply their own registry manipulation 
routines that do things like keep key
creation and access times, what user or program created
the key, etc., so later on it would be easier to delete old
cruft.

   But specifically, the power of unix, traditionally, was the 
orthongonality of the various command line tools and the ability to pipe 
output from one program into another.  Wouldn't it be rather 'cool'/nice 
to be able to manipulate and edit the registry using the same tools you 
can use on files. 

   Never have entirely figured out why, but accessing keys in the 
registry seems so dang slow and the only tools to mess with the registry 
are cumbersome and error-prone and designed to be dangerous and obscure 
to incline people not to edit it directly.  The concept of an editor, in 
this day and age not having an "Undo" feature.  Not having drag and drop 
-- but if it was a file system, the you could use explorer to drag/drop 
it and have automatic undo functionality.  MS likes to keep users 
ignorant and uninformed so they can play fast and loose with bad 
algorithms and code, hinder reverse engineering and create obstacles to 
using mixed-OS environments.

> Because the registry doesn't have the same set of
> invalid characters in names as the underlying filesystem, this mapping
> sometimes fails, as in the case of mounts values.  It might be possible to
> change the /proc/registry implementation to translate "/"s in key and
> value names to valid character combinations (e.g., URL encoding).  PTC.
> 	Igor
>  
   True, but it also would also seem prudent not to be the
only known (to me, at least) application to use a specific feature -- I 
could easily see MS restricting "/" from
key/value names in a future OS release, possibly, even, to
support their own Unix compatibility efforts.

   As for the registry concept, in general, I don't think it would be 
the worst idea to implement on Unix/Linux systems -- like 
/etc/sysconfig+/proc+multiple .<appname>.rc files.

   Rather than having each app use it's own method of storing config 
values, and many apps using 100 bytes out of a 4k allocation unit, it 
might not be so bad to have a "registry" file system type that would 
allow storing of small config values in many small spread-out randomly 
named and placed config files.  If you had a per-system, and a per-user 
file,
it would make saving the config state of a machine or a user's
preferences trivial to copy to a new machine, potentially.

Linda


--
   In the marketplace of "Real goods", capitalism is limited by safety
   regulations, consumer protection laws, and product liability.  In
   the computer industry, what protects the consumer?



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/