Editing XML and PostgreSQL with ferris REST.

With a few minor tweaks, one can now edit the contents of XML files and PostgreSQL tables with the libferris REST interface. The YUI web interface has been updated to allow that to easily happen. In the below video, example.xml is first shown and then instead of viewing it as a file, I choose to "read" it as a directory, causing libferris to sniff it out and work out that it can mount that file as a directory for you. The same can be done using "ferrisls example.xml" at the command line.

Notice that the read link is only offered on the XML files. This is because libferris tells the client that those are not natively "directories" but can be seen that way if you like.

I then simply click down to the "barry" XML element in the mounted XML file. Editing the barry entry will write the data back to the server asynchronously. The terminal is used to verify that things went on back.

The second browser tab shows a mounted PostgreSQL table which has ID and Message columns. If I select edit on the message column I get to update the tuple as desired. Notice that the data grid in the browser is updated when the data is saved on back by watching the "message" column in the browser. I then use psql to verify the update from the command line.

Other interesting possibilities include mounted log files being split into columns in the web view, or grabbing some data from plasma on the server, streaming data from gstreamer or zoneminder, or anything else that ferris can do as a VFS. And as I tend to want ferris to mount it all^TM, the sky should be the limit! Heh, so I got the catchphrase in there emes.

VFS in the Could? Libferris Web Interface...

I'm syndicating to planet KDE because things in the post might be of interest for KDE. I'd be overjoyed to see some of the features in KDE too, the more powerful the tools available to folks the better the future tools will be ;) So, on with the show... I decided to add REST and YUI stuff to libferris. This is still very much a work in progress in spare time... Luckily the heavy lifting is all done already in the libferris library.

The initial web interface is still fairly basic, the back and forward buttons are handled by the browser leaving only the parent button in the apps toolbar. Home and Heart are your home dir and bookmarks respectively.

Clicking on a row allows arbitrary annotation of that file. The annotations are stored in either native kernel level Extended Attributes or RDF. A feature I find very useful is that all metadata is presented via the same interface. As you can see the "Annotation" column in the listview is showing your own description of each file. You can filter or sort on annotation just as you can on the file name.

The search page allows you to find files by their text content (full text search) and/or their metadata. As I've mentioned in the past, the metadata indexing modules include many optimizations above using the native APIs. This includes indexed lookup on certain classes of regular expressions. Many naive query evaluations using regular expressions will result in a linear time complexity. And unless you have used explicit code to handle it, you are likely to enjoy this bad performance even with very advanced indexing libraries and databases.

Tags or "emblems" etc are also handled through the same metadata interface. The tagging sidepanel offers suggestions for existing tags as you type and allows you to create new tags as you attach them to files. Removal of a tag is just a click away.

Of course, clicking a filename shows you the file itself over REST. This allows you to stream video files over REST to the Nokia n9 for example. There is partial IO support and write support so I could include a fancy text editor or image editor component in there... Unfortunately YUI 3.5.0 doesn't seem to support "selections" in the datagrid, so that nice visual feedback will have to wait for yui 3.6.0.

LFSR & arduino: a subset in hardware

The Linear Feedback Shift Register might appear to be "random" but it is of course far from it. The first two words should make you suspicious of how random things are. Version 1 does the actual production on the arduino chip. I'm hoping to break out the logic onto the breadboard for a future version. The arduino would then be relegated to a provider of voltage and ground.



Since it is all rather predictable, it would be fun to have a second arduino with light sensors on it be able to come close to the existing model and then sync its own LFSR and output to the LFSR.

Pragmatically unlocking an n9, possible?

I have in mind an app to use RFID over the NFC hardware on the n9 to allow the phone to be unlocked by an RFID tag. This way the password can be nice and long for locking the device, but I don't have to interact with the virtual keyboard in order to use the phone. If the phone locks, I just tap the RFID tag to it, it unlocks, and I'm away. Yes, two phase would be a logical next step, but that assumes that the "lock" on the phone is very hard to break.

Reading the RFID on the n9 is the simple part, I have that working fine with physical keys. Unlocking the phone is proving not so simple. I was hoping that MeeGo::QmLocks::setState would do the trick, but it is not to be so as the API docs explain.

Anyone stumbled on a way to unlock the n9 from a program?

REST & Filesystems: A homage to plan9

In my previous post I mentioned, among other things, two things I want to hack together: An improved REST API for libferris, and KDE KIO integration for libferris. It occurred to me that these two, while able to be performed as distinct tasks, are better done as one. Or rather that the later can be coded to rely on the first being available. With a REST API and a Web server, a virtual filesystem inherits one of the great properties plan9 - filesystems as separate processes that can run on another machine and access data on a third machine.

Consider wanting to get at information from a PostgreSQL table from a mobile phone. The REST API might be on the "webserver" machine, while the database runs on dbserver. The phone talks to webserver sending GET/POST and receiving XML/JSON depending on it's preference. Using libferris, webserver talks to dbserver (by mounting it) and queries and returns results back to the phone.

This also lets the phone upload images via the REST API. Instead of setting up software on the phone, just use QML or HTML5 and http POST the image to the REST API using a path of "flickr://me/upload/" and have the server send that image onwards. Anything that libferris can mount and interact with becomes available over the light weight REST API, ready for QML/Javascript thumb interfaces. Other examples would be getting at a mounted Zoneminder over REST, or a webcam using mounted gstreamer.

Using REST like this also fairly nicely sweeps away language binding issues. Almost all languages can access http in some way. Sort of like CORBA without the IDL files and tools to create stubs for you. Hmm, a REST API IDL compiler for Qt with OAuth support... mmm...

Support libferris, get at ferris through KIO, and read about OTR messaging

I thought I'd see how well some pledgie tasks would do in the wild. Some of this code is stuff I've been wishing to write for a while but unable to make the time.

If you want to get at some of the funky filesystems offered by libferris from your KDE desktop, you might like to support my "KIO Slave for libferris" pledgie:



If you've always wanted to add support for Off-the-Record messaging to your project, or help entice somebody else in that direction, I have a tutorial article on offer here:



If you want a REST interface for libferris, listing directories and getting at files over HTTP/HTTPS, you can help make that happen here:



And finally, last for today but not least, if you want to get at jpeg images on your Zoneminder server using nice normal command lines like the following:

$ fcat zoneminder://server/monitor | okular -

Then you might like to throw a little loose change at the zoneminder plugin pledgie: