[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XMLFS for GSoC
From: |
Michael Walker |
Subject: |
Re: XMLFS for GSoC |
Date: |
Thu, 7 Apr 2011 13:46:02 +0100 |
> 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
- Re: XMLFS for GSoC, olafBuddenhagen, 2011/04/02
- Re: XMLFS for GSoC, Michael S. Walker, 2011/04/02
- Re: XMLFS for GSoC, Samuel Thibault, 2011/04/02
- Re: XMLFS for GSoC, olafBuddenhagen, 2011/04/05
- Re: XMLFS for GSoC, olafBuddenhagen, 2011/04/07
- Re: XMLFS for GSoC, Michael Walker, 2011/04/07
- Re: XMLFS for GSoC, olafBuddenhagen, 2011/04/07
- Re: XMLFS for GSoC, Michael S. Walker, 2011/04/13