Re: Files, Directories, Resources, Operating Systems
* Mark Overmeer [EMAIL PROTECTED] [2008-12-08 21:20]: A pitty that we do not focus on the general concept of OS abstraction (knowing that some problems are only partially solvable (on the moment)). Well go on. Explain how you would, f.ex., provide an abstract API over file ownership and access permissions between Win32 and Unix? I don’t see such a thing being possible at all: there are too many differences with pervasive consequences. The most you can reasonably do (AFAICT) is map Win32-style owner/access info to a Unix-style API for reading only. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Files, Directories, Resources, Operating Systems
* Aristotle Pagaltzis [EMAIL PROTECTED] [2008-12-10 01:10]: Well go on. Btw, I just realised that it can be read as sarcastic, which I didn’t intend. I am honestly curious, even if skeptical. I am biased, but I am open to be convinced. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Files, Directories, Resources, Operating Systems
On 2008 Dec 9, at 19:56, Aristotle Pagaltzis wrote: * Aristotle Pagaltzis [EMAIL PROTECTED] [2008-12-10 01:10]: Well go on. Btw, I just realised that it can be read as sarcastic, which I didn’t intend. I am honestly curious, even if skeptical. I am biased, but I am open to be convinced. BTW you can run into this issue even only considering Unix/POSIX: POSIX ACLs, AFS, NFSv4. I can see the point of a very simple base API with system-dependent extensions, but am likewise skeptical that one can be designed that isn't useless. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Files, Directories, Resources, Operating Systems
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 in addition to the usual CRUD operations. More detailed views of metadata might be the providence of OS-specific modules, as might different semantics for content (and even stringy metadata). But having this sort of simplified works-everywhere layer interposed should handle common tasks like reading, writing, and copying without making everyone replicate OS-specific variants. The basic operations above have a POSIXy flavor, but the underlying details shouldn't. For instance, allow me to read and write this thing != chmod 6xx, thing. I'm not saying this is an easy solution, just that it's worth the effort. Then again, I think File::Copy is a better choice than Csystem cp for publicly distributed code, so I'm already biased. -- Regards, Charles Bailey On 12/9/08, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On 2008 Dec 9, at 19:56, Aristotle Pagaltzis wrote: * Aristotle Pagaltzis [EMAIL PROTECTED] [2008-12-10 01:10]: Well go on. Btw, I just realised that it can be read as sarcastic, which I didn't intend. I am honestly curious, even if skeptical. I am biased, but I am open to be convinced. BTW you can run into this issue even only considering Unix/POSIX: POSIX ACLs, AFS, NFSv4. I can see the point of a very simple base API with system-dependent extensions, but am likewise skeptical that one can be designed that isn't useless. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH -- Regards, Charles Bailey Lists: bailey _dot_ charles _at_ gmail _dot_ com Other: bailey _at_ newman _dot_ upenn _dot_ edu
Re: Files, Directories, Resources, Operating Systems
On 2008 Dec 9, at 21:11, Charles Bailey wrote: 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 Group is problematic; I don't recall Windows having group ownership (as distinct from group ACLs), and AFS PTS groups are very different from Unix groups. As I said, I'm all in favor of such an API, just skeptical that a useful one can be devised. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Files, Directories, Resources, Operating Systems
* Aristotle Pagaltzis ([EMAIL PROTECTED]) [081210 00:06]: * Mark Overmeer [EMAIL PROTECTED] [2008-12-08 21:20]: A pitty that we do not focus on the general concept of OS abstraction (knowing that some problems are only partially solvable (on the moment)). Well go on. Explain how you would, f.ex., provide an abstract API over file ownership and access permissions between Win32 and Unix? I don’t see such a thing being possible at all: there are too many differences with pervasive consequences. The most you can reasonably do (AFAICT) is map Win32-style owner/access info to a Unix-style API for reading only. (I do not have time today for long emails... paying work to do :-( The short answer: Just like Path::Class or IO::File, I suggest an OO interface. That means that you may share methods between different OSes but it also may not be possible. Within this OO interface, you could design two abstraction levels: one which maps directly to the OS calls, like supports chown via some POSIX mix-in. On an other level, we attempt to unify environments. For the latter, you can think of methods like owner getter and setter, os_family or size. Even more to my likings is an additional super-level. In this case, the actual platform-dependent implementation does its best... Maybe something like: (still Perl5 style) $file-change_attributes(owner = $user, group = $group, readable = 1, ...); The core implementation tries as good and as bad as it goes to unify various kinds of attributes onto OS specific features, taking care of nastiness like change-order limitations. Typically becoming smarter over time. Real DWIMming, exploiting our joint knowledge and share this. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
