Re: XMLFS for GSoC

[Michael Walker]

> I did originally just plan to do xmlfs, but then I realised that most
> of the nontrivial code in the xslt translator and in unxmlfs would be
> the same - the directory-tree-to-XML parser, which shouldn't really be
> too hard. The only other nontrivial part of the xslt code is the
> libnetfs-based translator component, but as that's just presenting the
> transformed XML, that could probably just be copied straight from
> xmlfs. Thus, I don't think much extra work will really be needed for
> either unxmlfs or xslt.

Ok, I've had a go at making an xmlfs-directory-structure to XML
converter, and thought in more detail about what needs to be
implemented for each translator and what can be shared, and I've
concluded that I probably can get this done in the time available.

Shared nontrivial code:
  * XML to libnetfs read-only translator: partially done
     Partial compliance to XML spec (problem being the use of, eg
"foo0" rather than "foo[0]")

  * xmlfs tree representation to libxml2 representation: partially done
     Can descend down a directory tree and identify whether everything
encountered is a tag name, attribute, or text node. Dies with an error
if anything else is encountered. All that remains is having it build a
libxml2 representation of the tree.

  * Watch a file/directory for changes and run a function when there
is one: done

Unshared nontrivial code:
  * XML writing
     Not needed for xslt because, as far as I'm aware, XSLT is a
one-way mapping. I may be wrong however, so I'll look into this. All
that needs to be done for this is to update the libxml2 representation
of the XML document. This will be pretty tricky, as I'll have to learn
to use libxml2 properly, but completely doable.

  * Read support in unxmlfs
     unxmlfs takes an xmlfs-compatible directory tree and turns it
into an XML file, thus reading will be done via libtrivfs, with no
write support (I see no need/use for that). I haven't used libtrivfs
before, but hurdextras should provide more than enough examples for me
to learn.

The translators themselves will be implemented out of the following components:

  * xmlfs:
    * XML to libnetfs read-only translator
    * Watch a file/directory for changes and run a function when there is one
      * Update the presented directory hierarchy
    * XML writing

  * unxmlfs:
    * Watch a file/directory for changes and run a function when there is one
      * Update the presented XML file
    * xmlfs tree representation to libxml2 representation
    * Read support in unxmlfs

  * xslt
    * Watch a file/directory for changes and run a function when there is one
      * Update the presented directory hierarchy
    * xmlfs tree representation to libxml2 representation
    * Perform an XSLT transformation
    * XML to libnetfs read-only translator

I think that this is perfectly achievable in the time available.

-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org