In the next release of libferris (due out $DATE) there will be initial support for mounting dbus. Not everything can be mounted effectively, but interaction with simple APIs is very easy from the command line :)
DBus methods are callable just like postgresql functions. I also added the option to use the [] bracket pairs to call a method so that you don't always have to escape a call from bash.
Command lines can get longish with descriptive service and interface names.
fcat dbus://localhost/session/org.freedesktop.DBus.Examples.Echo/org/freedesktop.../org.freedesktop.DBus.EchoDemo/Random[]
But one major advantage this has is that you can use the file manager to browse a dbus filesystem. Of course you can then drag and drop a full method name (because its just a url after all) to the shell to add some arguments and whack return.
Handling the stranger input/output argument pairing is something that will be delayed until I actually need to do it. Wallet/Code patches welcome as usual ;-p
So there is now one fewer things on the list of things that libferris can not optionally mount.
C++, Linux, libferris and embedded development. Yet another blog from yet another NARG.
Friday, September 28, 2007
Saturday, September 8, 2007
DBus for filesystem metadata... now working for some types.
And now the DBus magic is complete... getting metadata out of process is quite simple for all clients in an async manner. Clients are nicely isolated from metadata extractors deciding to segv and the API is non blocking... yes it is a little bit slower to do this over the wire (in fact over two wires bidirectionally because the broker actually talks to a worker to do the actual work). But with libferris and its automatic RDF caching the hit is only felt the first time you extract for many of the more expensive operations anyway. On a multicore machine it can actually be faster because you can have many workers attacking files for metadata at once.
I pass the URL back in the signals so that clients don't have to worry about mapping reqid -> url in their process. Such annoying things should be done by the broker for you at the slight cost of sending URLs across process boundaries in both directions.
<node name="/net/sf/witme/libferris/Metadata">
<interface name="net.sf.witme.Libferris.Metadata.Broker">
<method name="asyncGet">
<arg type="s" name="earl" direction="in"/>
<arg type="s" name="name" direction="in"/>
<arg type="i" name="reqid" direction="out"/>
</method>
<signal name="asyncGetResult">
<arg type="i" name="reqid" />
<arg type="s" name="earl" />
<arg type="s" name="name" />
<arg type="ay" name="value" />
</signal>
<signal name="asyncGetFailed">
<arg type="i" name="reqid" />
<arg type="s" name="earl" />
<arg type="i" name="eno" />
<arg type="s" name="ename" />
<arg type="s" name="edesc" />
</signal>
I pass the URL back in the signals so that clients don't have to worry about mapping reqid -> url in their process. Such annoying things should be done by the broker for you at the slight cost of sending URLs across process boundaries in both directions.
<node name="/net/sf/witme/libferris/Metadata">
<interface name="net.sf.witme.Libferris.Metadata.Broker">
<method name="asyncGet">
<arg type="s" name="earl" direction="in"/>
<arg type="s" name="name" direction="in"/>
<arg type="i" name="reqid" direction="out"/>
</method>
<signal name="asyncGetResult">
<arg type="i" name="reqid" />
<arg type="s" name="earl" />
<arg type="s" name="name" />
<arg type="ay" name="value" />
</signal>
<signal name="asyncGetFailed">
<arg type="i" name="reqid" />
<arg type="s" name="earl" />
<arg type="i" name="eno" />
<arg type="s" name="ename" />
<arg type="s" name="edesc" />
</signal>
Subscribe to:
Posts (Atom)