xdg Digest, Vol 12, Issue 28
elanthis at awesomeplay.com
Tue Mar 8 16:15:30 EET 2005
On Tue, 2005-03-08 at 14:34 +0100, Timo Stuelten wrote:
> On Mon, 7 Mar 2005 Sean Middleditch <elanthis at awesomeplay.com> wrote:
> > I'm thinking something along those lines, yes. The "important" items
> > would have their own accessor functions (and may be stored in a more
> > optimized form in the metadata structure), but it would basically just
> > be a dictionary with strings for keys and values.
> > The "important" items would file size, file type, modification date,
> > creation date (=modification if backend doesn't support this), encoding
> > (extracted from mime type where appropriate), and of course file name.
> > Did I miss anything?
> Access rights (ACLs)/Owner? At least canWrite/canRead for the current
Writable/Readable for the current user makes sense, yes. ACLs are hard
since they come in so many forms... It would probably make sense to
support some "standard" variations here; a scheme for classic UNIX
permissions, another for POSIX ACLs, and so on. I think most access
control methods can be mapped to only a small handful of models.
I'll have to look into POSIX ACLs more and see how/if the API wraps
classic UNIX permissions.
> Files can have multiple mimetypes (e.g. XML-Files). How to return them?
> (see XDG-mimetype definitions)
Using the XDG mimetype definitions makes sense - whatever it would
report for the mimetype is what DVFS would report.
> Apart from the basic data: How about some xml-like namespace
> scheme, where the returned key are prefixed by e.g. "xdg:" (or "dc:" where appropriate), so there would be no
> key collisions, semantics can be definied somewhere more formally (like
> dc) and fs having their own semantics can use their own prefix?
> Should be no overhead this way and it's probably easier to localize?
Sounds like a good idea, yeah.
Sean Middleditch <elanthis at awesomeplay.com>
More information about the xdg