freeswitch/libs/iksemel/HACKING
Michael Jerris 83f4a9dc2f add iksemel to in tree libs
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@3756 d0543943-73ff-0310-b7d9-9358b9ac24b2
2006-12-20 15:45:14 +00:00

72 lines
2.8 KiB
Plaintext

License:
========
iksemel is developed and released under GNU Lesser General Public License.
A copy of the license can be found in the file COPYING. You should read it
before sending patches to the iksemel, since it is implicitly assumed that
your patches are also submitted under the LGPL license.
Roadmap:
========
Main goal of the iksemel is removing complexity from programs using the
library and the library itself. This is the reason why only a subset of XML
is supported. Some things like UTF16, entity definitons, DTDs will be eventually
implemented when we found ways to implement them without adding
too much complexity to the iksemel code. Somewhat external standarts
(XPath, XQuery, XSLT, vs) will probably not make it into the iksemel.
* validation
I think easiest way to add this feature is writing another parser based on the
sax parser which parses a dtd (either from sax parser's markup callback which
needs to be implemented or from an external source via iks_vsax_set_dtd() call)
and checks the arguments of sax callbacks. Using it via dom or stream parsers
can require some clever tricks. there are also xml schemas. they are easy to parse
(it is xml anyway) but can be hard to apply.
* utf16
There are two sides of this. Improving parser to accept utf16 can be relatively
easy. But on the client side things can get confusing. What will be the default
character set used by iks_new(), iks_insert_cdata() and similar functions? and
how they will allow other charsets to be used. Supporting more than utf8 and
utf16 is more difficult. Hopefully there is no immediate need for this. Jabber
uses only utf8 and you can use iconv if you are using another charset in your
application. Btw, there is also byte order issue which is silly. Inventor of BOM
crap must be killed.
* jabber roster
Roster handling generally depends on the UI system used. But I think a generic
roster handler which parses roster result, pushes, presence changes and
allows application to access and display this data can be useful. Challenge
here is making it UI independent and extensible by the application.
File Layout:
============
doc/
* iksemel.texi Documentation in texinfo format.
include/
* common.h Internal header for some common definitions.
* iksemel.h Library API
* finetune.h Default memory allocation sizes.
src/
* ikstack.c Memory management functions.
* utility.c Small string utility functions.
* iks.c XML tree management.
* sax.c SAX parser.
* dom.c DOM parser.
* stream.c Stream parser.
* sha.c SHA1 hash functions.
* jabber.c Jabber utilities.
* filter.c Packet filter for Jabber.
test/
(self test programs)
tools/
(varius utility programs)