Parrot "standard libraries"

Geoffrey Broadwell geoff at broadwell.org
Thu Jul 30 00:30:16 UTC 2009


OVERVIEW
--------

TT #593 states that we should expand our current set of "standard
libraries" and improve the ones we currently have (curses, OpenGL,
PostgreSQL, SDL, etc.).

During the most recent #parrotsketch, Allison pointed out that this
umbrella ticket needs to be broken into separate tickets, one for each
current library and one for each new library we want to add.  We can
then schedule the individual tickets (and any prerequisites) over the
next several releases.  We need to decide which new libraries we want to
provide, and what Parrot features they will require.


MY LIST
-------

I'd nominate the following new libraries; comments welcome:

* zlib
* OpenSSL or GnuTLS
* SQLite
* D-Bus
* libxml2 or Expat
* Qt or GTK+


DETAILS
-------

* zlib

The standard implementation of DEFLATE compression, which is used by
quite a few standard tools and protocols.  Compression needs to be rock
solid and really fast, so we should just wrap the standard library
instead of reimplementing it.

I can imagine some memory management and string/buffer handling bugs
might be flushed out by this, but no new Parrot features required as far
as I can see.

* OpenSSL or GnuTLS

Encryption should be done in a library written by paranoid crypto
specialists; we should outsource (not reimplement) all the crypto we
need, starting with one of these libraries.

For security reasons, Parrot will need to be able to guarantee that a
buffer or string has been wiped clean upon request, and has not merely
scheduled that task for later or assumed that releasing the memory is
sufficient.  Also, we need to document very clearly which ops/methods
will copy a string/buffer and which will merely provide a new reference
to an existing one, so that users can be careful not to accidently make
copies of sensitive data and neglect to wipe them.

* SQLite

We have a wrapper for a client-server SQL database (PostgreSQL), but we
should also support an embedded one.  SQLite is the standard in this
space.

Offhand I can't think of any new Parrot features required to support
this library.

* D-Bus

D-Bus is the freedesktop.org IPC system required to communicate with
most of the daemons and components on modern *nixen.  There is a port of
the reference library to Windows, as well as bindings/reimplementations
for many languages.

D-Bus is a fundamentally asynchronous protocol, and Parrot will need a
working event system with the ability to watch sockets, schedule
callbacks, support timeouts, and so on.  Also, the NCI system may need
expanded support for native types in order to support the full D-Bus
set.

While the raw D-Bus protocol uses binary marshalling, it requires a
high-speed XML library (libxml or expat for the reference code) to
support its introspection system.

* libxml or Expat

A really solid, speedy XML library will be very useful for when PGE
isn't fast enough, and reduces pressure to prematurely optimize it.
That said, neither of these are really *required* if we can provide
half-decent XML performance soon using Parrot's existing tools.

Excepting for pushing hard on the NCI and string/encoding subsystems,
I'm not aware of any new Parrot requirements here, though I don't know
offhand whether the current limited Parrot NCI callbacks are sufficient.

* Qt or GTK+

The standard open source GUI toolkits -- there are many others, but if I
had to pick just one to ship by default it would be one of these.  I
learned GTK+ back in the dark ages, and still run mostly GTK+-based
applications, but I gather that Qt is the more powerful toolkit of the
two and provides a more "native" look on each operating system.  There's
nothing that prevents us from wrapping both toolkits, but either one
will be a large job by itself, probably taking some months to complete.

Both of these have native mainloops, but I seem to recall that in recent
years they support interfacing with other mainloops seemlessly; Parrot's
event loop will need to support this.  Also, these APIs are very large
and it is highly likely that we will find things that the current Parrot
NCI does not support well.


-'f




More information about the parrot-dev mailing list