[Linux-aus] Grant Scheme: libferris, evolution and libxml
monkeyiq at users.sourceforge.net
Thu Jun 2 19:17:02 UTC 2005
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 at 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  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).
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:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.linux.org.au/pipermail/linux-aus/attachments/20050602/20de8556/attachment-0001.pgp
More information about the linux-aus