xdg Digest, Vol 12, Issue 28

[Sean Middleditch]

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 
> user?

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.

> 
> -Timo-
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>