I''ve been playing with similar sorts of problems when creating an OO
model for packaging metadata, that could supposedly represent the data from a
.rpm or a .deb or whatever.
The first thing I did was set up a method where if we're outputting
eg. an RPM, it will mark every piece of metadata it uses, and then afterwards,
the core system will emit warnings about all the things it didn't use.
Something similar could possibly be done; we'd simply need to give the user
control as to where the warnings end up.
Note that I also agree with the guy who said that we need
system-specific calls, and then an abstraction layer on top of that.
On Wed, 10 Dec 2008, Aristotle Pagaltzis wrote:
* Charles Bailey <[EMAIL PROTECTED]> [2008-12-10 03:15]:
It may well be that a fine-grained interface isn't practical,
but perhaps there are some basics that we could implement, such
as
- set owner of this thing
- (maybe) set group of this thing
- give owner|everyone|?some-group the ability to read
from|write to|remove|run this thing
- tell me whether any of these is possible
- make the metadata for this thing the same as the metadata for
that thing
- tell me when this thing was created|last updated
There are many problematic suggestions here. Some examples:
? Unix does not track file creation datetime at all.
Emit a warning.
? The concept of making a file runnable doesn?t even exist on
Windows: that property is derived from the filename extension.
So when they read it, make a guess based on the extension, and when
they write it, emit an error.
? Delete permission on a file is a concept that doesn?t exist on
Unix. To be able to delete a file, you instead need write
permission on the directory it resides in.
So when they read it, figure it out, and when they write it, emit an
error.
Furthermore, in Win32, files and directories can inherit
permissions, so the fact that a file has certain effective
permissions does not mean that these permissions are set on
the file itself. But if you set them on the file itself, you
dissociate it from the inheritance chain. So reading permissions
and then setting them the same, without changing anything, can
still have unwanted side effects. Or if you try to make the API
smart, and so make it set permissions only when they constitute
a change from the effective permissions, then conversely the user
no longer has a way to dissociate the file from iheritance if
that *is* what they wanted. So the concept of inheritance must
be exposed explicitly.
Or, you could pick a consistent model, and then let the user use the
lower-level interface if they want to be more specific.
This is the primary issue I was thinking of when I said that some
differences between Win32 and Unix have such pervasive effects
that it seems impossible to provide even a rudimentary abstract
interface.
Try "rudimentary *optional* abstract interface", where the other
option is system-specific.
:)
---------------------------------------------------------------------
| Name: Tim Nelson | Because the Creator is, |
| E-mail: [EMAIL PROTECTED] | I am |
---------------------------------------------------------------------
----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----
