> 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
