Re: XMLFS for GSoC

[Michael Walker]

> So the idea is that one would launch an XSLT translator, with a XSLT
> style sheet as input, on top of an xmlfs directory, and the result would
> be a file representing the output of the XSLT processor?

Yes, that's what I was thinking. Though, being able to run it on top
of an XML file should be pretty simple, too.

> BTW, I fear that the scope of your proposal is a bit excessive. The
> summer tends to be over pretty quickly -- unless you are extremely fast,
> I don't think it's likely you will get past making xmlfs and perhaps
> unxmlfs fully functional...

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.

Additionally, I did go from zero Hurd programming knowledge to
implementing a working file change monitor in a couple of days, I do
tend to pick things up pretty quickly.

I think I'll have a go at the directory-tree-to-XML parser tonight and
see how I feel about the proposal after that, and revise it if
necessary.

Thanks for the comments.

-- 
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