VIO - Visual IO Agents

nf2 nf2 at scheinwelt.at
Tue Jan 23 08:17:40 PST 2007


hi, maybe you will find this interesting/worth discussing. i'm currently 
working
on a prototype of:

VIO - Visual IO Agents

(a possible successor of KIO Slaves and Gnome-VFS modules)

one idea for VIO is to standardize the interface between clients
and vfs-protocol handlers (agents) by using a tiny point 2 point
socket communication library written in plain C that protocol
handlers can be used in a cross-desktop way.

the second idea is that access to remote resources can be provided
by ordinary gui-based applications. (something
similar old fashioned gftp, winscp, file-roller, kftp...), but with
a stripped down gui, most of the time resting as (blinking)
icon in the systray.

you would just launch such a client application, connect to a server
or open a zip-file and the resource would become accessible to *all*
applications and filemanagers through a local socket in the tmp dir:

/tmp/vio-{username}/ftp%user%ftp.xyz.org

thus, there would probably be no need for standardizing login dialogs,
password storage interfaces, remembering locations etc...
the user would have full control on
connections, he can monitor them, cancel them etc...

mounting a resource means launching an agent, by pressing the
agents "close" butten the resource is unmounted. there could be a
"preferred protocol handler" config table somewhere to enable
auto -launching.

it doesn't matter if the user runs the kde, gnome or whatever
implementation of such a "protocol - provider",... the development
of protocol-handlers would become completely decoupled from
desktop development...

the design of libvio would be quite simple -
just scanning the /tmp/vio-{username}/ directory for sockets and
getting file/directory access through a
simple binary point to point socket protocol...

currently i see no need for a centralized "vio-daemon".


excerpt of the documentation:

VIO Agents
----------

Vio agents provide acess to certain virtual file-system
resources through a socket protocol. They can run as seperate process
or inside the client as threads.

There are four types of VIO-Agents

1) SHARED
   have a GUI and accept multiple connections through a
   local socket in a specified directory:
   /tmp/vio-{username}/ftp_user at ftp.xyz.org  
   they handle protocols like ftp:, smb:, zip:...
   they usually run as one instance per resource
   (like user at ftp.xyz.org) and act as a kind of proxy.
  
   you can think of them as stripped down versions of
   applications like gftp, kftp, file-roller,...
   they might be minimized to the systray and only
   pop up for authentication, etc... 
   the user can monitor activity, control them, close them
   with their the GUI.
  
2) PRIVATE
   are launched by the client application and usually don't
   have a GUI. they handle local resources like file:, computer:
   usually they are single threaded like KIO slaves.
   communication goes through a pair of pipes - usually stdin/stdout
   of the agent process.
  
3) PRIVATE-AS-THREAD
   same as 2) but running inside the client as threads, using
   a socket-pair for communication.

4) SPECIAL
   like 2) or 3) but handle special tasks like file-copying,
   monitoring, launching etc...
  
  
VIO Library (libvio)
--------------------

both sides - the clients and agents link to the small C-library libvio.so.

libvio provides a low level API to launch and communicate with VIO agents
and to run vio-jobs. the interface is message-loop style
on the client-side and KIO-SlaveBase style on the agent side.
on the client side it is designed in a way that various nicer high-level
synchronous and asynchronous APIs (like KIO::Jobs, Gnome-VFS and
future g-vfs can be wrapped around.

public interface to be used on the client side:
   vio.h, vio_file.h, vio_codes.h
public interface to be used on the agent side:
   vio_agent.h, vio.h, vio_file.h, vio_codes.h


VIO Job types:
--------------

get      : read entire file
put      : write entire file
file     : open/read/write/seek file
ls       : read directory
copy     : copy file
move     : move file
stat     : get filinfo
charttrs : change file attributes
mkdir    : create directory
rmdir    : remove directory
delete   : remove file


VIO Socket Protocol
-------------------

The transport mechanism in vio is
message-container based.
the wire format of the messages looks like this:

[ 16 byte header ; body: byte array ]

typedef struct {
    int magicNr;
    int sequenceNr;  /* sequence number (job id) */
    int typeID;        /* message type */
    int bodySize;
} VioTransMsgHeader;

a connection can only handle one job at a time, der sequenceNr is
only used to throw away messages from previous jobs (like cancel
messages which arrived too late)

concurrent jobs will trigger launching another agent (for
private agents) or opening a second connection to a shared
agent.

the internal tranport machanism is defined in vio_trans.h. 
Structure type messages (like directory entries) often hold their
data in a VioTransStruct - a dictionary type (like KIO:UDSEntry)
which can be serialized. see vio_trans_struct.h.

D-Bus will not be used for the core tasks of VIO, but might be used
for file/dir change notification and for emitting agent
startup/shutdown events. not sure yet.


VIO Messages
------------

VioMessage is a kind of variant data type, which has the following fields
- depending on the message type. VioMessage is the data-type visible
to the library user. access to the fields is provided
through getter and setter functions. you should never access the
internal structs directly.

pseudo definition of message types and fields:


COMMAND_* Message               # invoke a job
[
    location : viofile
    (targetLocation) : viofile   # for copy/move operations
    commandOptions : enum
]

/* agent redirection happens when an agent cannot handle a task
himself. he might delegate the job to a child agent for instance. */

REDIRECT_TO_AGENT Message
[
    specialAgent : enum      # for instance the "file copy agent" / 
otherwise 0
    socketName/Port  : string/int
]

PROGRESS Message
[
    total  : size
    count  : size
    validFields  : bit[]
    unit  : enum             # unit of the "total", "count" fields
                             # (bytes, percent,...) 
    stage  : enum            # authentication, waiting, connecting, 
downloading, uploading...
]

DATA_CHUNK Message
[
    data  : byte[]
    size  : size
]

FILE_INFO Message
[
    location : viofile
    name : string
    user : string
    group : string
    hasPermissions : bool
    permissions : bit[]
    size : size
    iconname : string
    hasMimetype : bool
    mimetype : string
]

CANCEL Message
[
]

ERROR Message
[
    code : enum
    message : string
]

DONE/FAILED Message
[
    returnValue : enum   
    willLiveUntil : date        # date when the connection will be 
become invalid
                                # and might be closed.
                                # connection should not be reused after 
this "date"
]

...

Message-Communication Schemes
-----------------------------

___ GET Job ___

[client]   ...   [agent]

+===== CMD_GET ========>
<---- REDIR2AGENT------+
<----- PROGRESS(*) ----+
<===== DATA_CHUNK =====+
<===== DATA_CHUNK =====+
<===== DATA_CHUNK =====+
...
-------- CANCEL ------->
<------- ERROR --------+
<===== DONE/FAILED ====+

___ PUT Job ___


[client]   ...   [agent]

+===== CMD_PUT ========>
<---- REDIR2AGENT------+
<----- PROGRESS(*) ----+
+===== DATA_CHUNK =====>
+===== DATA_CHUNK =====>
+===== DATA_CHUNK =====>
...
-------- CANCEL ------->
<------- ERROR --------+
<===== DONE/FAILED ====+


___ COPY Job ___

[client]   ...   [agent]

+===== CMD_COPY =======>
<---- REDIR2AGENT------+
<----- PROGRESS(*) ----+
-------- CANCEL ------->
...
<------- ERROR --------+
<===== DONE/FAILED ====+

MOVE Job

see COPY Job


___ LS Job ___

[client]   ...   [agent]

+====== CMD_LS ========>
<---- REDIR2AGENT------+
<----- PROGRESS(*) ----+
<===== FILE_INFO =======
<===== FILE_INFO =======
<===== FILE_INFO =======
...
-------- CANCEL ------->
<------- ERROR --------+
<===== DONE/FAILED ====+



___ STAT Job ___

[client]   ...   [agent]

+===== CMD_STAT =======>
<---- REDIR2AGENT------+
<----- PROGRESS(*) ----+
<===== FILE_INFO =======
-------- CANCEL ------->
...
<------- ERROR --------+
<===== DONE/FAILED ====+



___ CHATTRS, MKDIR, RMDIR, DELETE Jobs ___

[client]   ...   [agent]

+===== CMD_COPY =======>
<---- REDIR2AGENT------+
<----- PROGRESS(*) ----+
-------- CANCEL ------->
...
<------- ERROR --------+
<===== DONE/FAILED ====+


___ FILE Job ___

[client]   ...   [agent]

+===== CMD_FILE =======>
<---- REDIR2AGENT------+
<----- PROGRESS(*) ----+

+===== READ N =========>
<===== DATA_CHUNK =====+
...or...
+===== DATA_CHUNK =====>
<===== WRITE_ACK ======+
...or...
+====== SEEK ==========>
<====== SEEK_ACK ======+
...
-------- CANCEL ------->
...
<------- ERROR --------+
+====== CLOSE =========>
<===== DONE/FAILED ====+


...

regards,
norbert




More information about the xdg mailing list