DVFS Metadata

nf2 nf2 at scheinwelt.at
Wed Mar 9 01:48:46 EET 2005

Sean Middleditch wrote:

>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.
I wonder whether DVFS should use "weak types" (Variants) for *all* 
variables (like metadata, callbackdata, open options, dir-entries,...).

Convenience functions like get_size(metaData) could help to 
compose/decompose those structures on the client *and* backend side...

**** DVFS: Very sketchy proposal for the internal backend interface ***

*   Hierarchical data structure - can contain:
*   byte arrays, primitives, key/value maps,...
*   Can be serialized to transport document data, callback data, 
metadata... via IPC.
class DVFSVariant {
    byte[] serialize();   // like DBUS Serialization?

*   DVFS Session Object - A "virtual mount" - like a certain user at server 
class SessionRef {
    DVFSVariant sessionData;
    DVFSConnectionPool outboundConnections;

*   Backend core class - instantiated as backend is loaded via dlopen
class VFSModule {


    DVFSVariant getCapabilities(); // get the whole Interface definition
    DVFSVariant checkCapabilties(DVFSVariant requestedFeatures);

*   VFSModuleOps (Instance per Client Connection and VFS Target Session)
*   Operation are synchronous (blocking) and optionally converted to 
async events
*   in the VFS daemon or a thread in the client process.
class VFSModuleOps {

    // **** virtual methods - implemented by backends ****

    // synchronous Streaming Interface

    VFSResult open(URL url, FileHandle h, DVFSVariant openOptions);
    VFSResult read(FileHandle h, DVFSVariant dataOrInfo); // could also 
return Metadata as Map
    VFSResult write(FileHandle h, DVFSVariant dataOrCommand);  // can 
also send a special command like seek
    VFSResult close(FileHandle h);
    // Directory Listing (Like a SQL query and Resultset - order, 
filters and columns can be defined)
    VFSResult openDir(URL url, DirHandle h, DVFSVariant qryDefinition);
    VFSResult readNextDirEntry(DirHandle h, DVFSVariant dirEntry);
    VFSResult closeDir(DirHandle h);
    VFSResult getAttrs(URL url, DVFSVariant fileAttrs);
    VFSResult setAttrs(URL url, DVFSVariant fileAttrs);
    // atomic operations (like mount/unmount) - finished after return.

    VFSResult doAtomic(URL url, DVFSVariant input, DVFSVariant output);

    // **** used from inside the backend code ****

    boolean getStopFlag(); // stop everything?
    VFSResult callback(DVFSVariant callbackData, DVFSVariant 
callbackResponse);  // calls back to Client
    VFSResult authCallback(DVFSVariant callbackData, DVFSVariant 
    ClientConnectionRef getClientConnectionRef();
    ThreadData getThread();
    SessionRef getSessionRef(); // get Session ("Virtual Mount") Reference


More information about the xdg mailing list