Subject: Re: Device Properties: The Next Generation
To: None <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 02/20/2001 09:50:08
> So, I think we're looking at this from different angles.
> I can construct some where you _need_ that behaviour, but they seem
> However, it seems obvious to me that an inherently useful feature of a
> good properties interface would be _not_ exposing data where it
> shouldn't be known.
> No, properties are available to all. If you want to restrict
> access, then you're building a filesystem.
This seems like ... a red herring.
You already have:
(3) inheritance (a primitive type of access control, kinda)...
You already have a file system.
> Really, this kind of interface needs _some_ method of limiting the
> propagation of inherited properties. I've brought up several; that
> one seems the simplest.
> I completely and utterly disaggree. Properties are a way to
> publish data to other entities that may be interested in them.
> This is usually information describing a device node. If there
> is any confidential information it should not be placed in a
> property, since then it would be readable by anyone.
It's not a matter of "confidential." It's a matter of, no need to
know it, so why expose it and allow the ability to create bizarre bugs
though weird programming errors.
Here's a question: why support PROP_INHERIT at all?
i.e. why not _always_ inherit from parents?
It seems to me what you have right now is:
I.e., you search only your locally attached properties, or you search
the entire tree up to the root.
It seems to me that that's missing the classic "1" (or a more abstract
version of that).
If your claim is, the protocol is defined and can be followed to
correctly produce a property using inheritance, then you shouldn't
need to specially turn on inheritance.
If your claim is that you _should_ need to specially turn on
inheritance, then you're missing support features that I think are
important: some way of limiting the inheritance in cases where it's
"known" (by the protocol) not to be desirable.
You can't really pick both at the same time...