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

- 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

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                           |

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-

Reply via email to