Hi, Bely.

2010/5/14 Dmitry Bely <dmitry.bely@gmail.com>

> How "heavy-weight" is Camomile? I was a bit scared with the size of
> its distribution. Currently I use under Windows the following my own
> simple Unicode-support module (implemented via
> WideCharToMultiByte/MultiByteToWideChar Win32 API functions). Maybe
> it's time to switch to Camomile?
>
>
The size of the package is due to mapping tables of character encoding and
localization data.  they occupy several mega bytes on the disk but it is
nothing by today's standard.  If you still care, you can delete any .mar
files in charmaps, locales, mappings directory.  (Deleting source files in
these directory is not recommended, since it could cause a failure of
compilation.)  If you delete such files, related encoding and locales do not
function, but other functionality is intact.

As for memory consumption, character mapping tables and localization data
are loaded to the memory when they are required.  So if you do not use them,
they are dead on the disk.  After being loaded to the memory, they are
retained by weak hashtable, therefore, when they are no longer used, GC
releases them.

Some modules load data from database directory during initialization.  They
persists the end of the execution, but these data are usually small (mostly
some kilobytes in the marshaled form, only allkey.mar which used in uCol
module is >100k bytes (*)).  You can avoid loading them by not linking these
modules.

Finally, the programming style to use Camomile would be a bit heavy, since
Camomile uses functors a lot.  In fact, the library itself is a functor
which takes modules containing initialization parameters.

Heaviness aside, Camomile does not provide OS integration, which might be a
problem for you.  I tried POSIX integration but abandoned it by the reason
which I no longer remember :-)  But, you can use UTF16 module to access wch
array, since Windows wch is a 16-bit integer.
(UTF16.t is 16-bit integer array implemented in bigarray module.

(*) I noticed allkey.mar can be retained by weak pointer as well (currently,
it is held in Lazy.t).  I will fix it in the next release, maybe.

Feel free to ask further questions.  I would be grad to answer them.

Best,
-- 
Yoriyuki Yamagata
yoriyuki.y@gmail.com