Hi, Looking over the past grant requests I'm not too sure on what is accepted and what is not applicable. Also the submission part at the top left of http://www.linux.org.au/projects/grants states to send to committee@linux.org.au though this list appears to be the desired destination. So this emial will either be a few laughs and a "cheeky monkey" comment or two or a replacement monitor for me. I am the author of libferris [1,2]. In line with the "will hack for food" image on the above grants page and with the recent death of my primary monitor I have proposal in exchange for a new monitor. A quick sloccount of the project gives the following, without including other libraries which are split of (eg, libferrisstreams, libstldb4) Totals grouped by language (dominant language first): cpp: 112043 (98.59%) ansic: 966 (0.85%) perl: 388 (0.34%) sh: 249 (0.22%) Total Physical Source Lines of Code (SLOC) = 113,646 I have a few proposals. My original thoughts were to port libferris from using xerces-c to using libxml. A cooler thought is to finally get around to allowing libferris to mount Evolution. I'd favour the latter option of the two just because I think its cooler ;) Xerces-C / libxml option: libferris currently uses xerces-c for its XML support. It seems that many distros don't package xerces-c [3] and instead only support xerces- j. My plan is to allow libferris to use either xerces-c or libxml2 for its XML handling though adding libxml2 optional support is quite a chunk of work. Given that for me its not exactly exciting work I thought of this grant scheme to provide incentive for the "port". At first I propose a limited port such that libferris can be used with libxml2 instead of xerces-c depending on compile time options. I'd like to keep xerces-c support as an option aswell so that the compiler gets the choice of how they want their libferris to be. Over the time libferris has moved to using XML as a basis in many parts. A full port I'd imagine to take about 3 weeks full time. The limited initial port should take less time than that but I'd not expect any change from a week solid hacking (7 fairly full days). Evolution option: I think being able to mount Evolution would be very cool not only because mounting mail is a nice fit but it also allows linking Contacts in evolution with files in the filesystem and other semantic web(ish) stuff to be done on the desktop. I notice that the evolution headers are not C++ friendly (using delete as a virtual table entry name is bad, mkay). Also some libraries which will be needed from Evolution are not setup to be easy to pick off from the pkg-config files. The main reason I've not done the following is due to time restrictions. This proposal could justify the addition. Add support for mounting mail including showing attachments as separate files and loading subdirectory inodes on demand (ie, not having to readdir() to find Inbox/FromFoo folder), exporting contacts including metadata as Extended Attributes within libferris and possibly exporting your calendar as a filesystem depending on if I can cleanly abstract this last point. Date: 2 June 2005 Project Name: libferris Aim of Project: Either the above libxml2 or evolution mounting option. I also highlight the efforts already put into creating and expanding libferris to date as support for this request. Person Resposible for Request: Ben Martin Request: A high(ish) end LCD screen to provide incentive for the port/work ;) For example SAMSUNG 21" 213T LCD which currently goes for about $2000. [1] http://witme.sourceforge.net/libferris.web/ [2] http://www.linuxjournal.com/article/7771 [3] http://xml.apache.org/xerces-c/
Attachment:
signature.asc
Description: This is a digitally signed message part