DVFS Metadata

[Sean Middleditch]

On Tue, 2005-03-08 at 18:16 +0100, Timo Stuelten wrote:
> On Tue, 8 Mar 2005, Sean Middleditch wrote:
> 
> > I'll have to look into POSIX ACLs more and see how/if the API wraps
> > classic UNIX permissions.
> I don't know the API for POSIX, AFS or NTFS ACLs, so the following 
> may be wrong :) (I used  http://www.ee.ust.hk/~vlsi/tutorials/afs.htm 
> (AFS) and "man smbcacls" (NTFS)).
> May be they are worth to look? If not drop this part...

Yeah, if any real effort is put into ACLs beyond just "can read" and
"can write," it makes sense to be sure it can support *all* ACL systems
out there.

<snip/>

Hmm, perhaps the API should focus on simply providing a list of
privileges and data in the form "<priv>:<data>".  The meaning of both
would be completely up to the backend, but with some "standard"
privileges laid out with common names.  That would make the system
flexible to any backend's needs, and at least CLI tools and scripts and
such could adapt easily to those backends as they're just strings.  GUI
apps would need special considerations, though...

The other option is to provide a wide variety of built-in privileges,
and allow a backend to describe which privileges can be used with its
ACLs.  Then GUI tools can adapt to a backend a lot easier and CLI tools
and scripts can still work pretty easily.  If any new and weird
privileges are invented for some particular backend, though, D-VFS and
would have to be updated.

> 
> > Using the XDG mimetype definitions makes sense - whatever it would
> > report for the mimetype is what DVFS would report.
> The DVFS adds further mimetypes to the types delivered by fs like http? 
> OK - for most filesystems it has do be done anyway and doing it in 
> the DVFS layer avoids wrong/misleading mimetypes. 
> 
> Other silly questions:
> 
> What about file xattrs? Simply return them using some prefix for
> unknown keys and mapping known keys to special DVFS-keys (e.g. mimetype)? 
> (usually they have an prefix already, e.g. "system." for ACLs)? 
> Without additional prefix, they may interfere with other namespaces.

Yeah, the plan is to just drop them in as-is, in such a manner as to not
conflict with other special keys.  An "xattr" namespace makes sense.

Of course, if we have only a couple pre-defined namespaces, we don't
really need to add the memory and processing overhead of putting the
namespace in the strings - we can simply group the keys accordingly.
API would be something roughly like:

vfs_metadata_get_mimetype(md); /* get mime-type */
vfs_metadata_get_size(md); /* get file size */
vfs_metadata_get_xattr(md, "foo"); /* get 'foo' attr */
vfs_metadata_get_acl_all(md, &acl_list); /* store ACLs in acl_list */

Basically, make the metadata structure and API a little more than just a
simple key/value list.  I don't like the idea of interface complexity,
but then, a single function call like get_size() is a lot easier than
get_attr("file/size") [for one reason, its got type safety and you don't
have to wait until runtime to find out you typed in the wrong key,
although macros can get rid of the second problem] but I think this is
probably the right way to go.

> 
> How to return multiple values in the value of a key-value-pair? 
> (listxattrs returns an int giving the number of elements and a 
> list with \0 as delimiter. Maybe the .desktop-style is better for 
> other languages than C? Something like "key=value1;value2"?)
> 
> Force the encoding of (all strings used in DVFS|metadata) to be UTF-8?

That's definitely a good idea, where possible.  We can't force the
encoding of extended attributes, but then, any use of those is
application specific anyhow, so it's really honestly not our problem.

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