I mean, it is cool to have a filter interface that we can handle
homogenously, but it is not so cool if we need a
pdf_stream_install_filter that gets a fixed enum to identify the
filter... what if the library client wants to define a new kind of
filter? He can't...
We dont plan to allow the client to define new filter types without
modifying the library.
Even worse, stream backends have a defined interface but we are
using a switch () {} on every stream function to dispatch the
correct one instead of using function pointers...
the same for the backends. The user can define new filesystem types
that she can then use as a backend for the streams.
My proposal is to define a clear metodology for polymorphic types
that makes the gnupdf API more consistent and that causes less
coupling among modules. My purposed method is the one used by
GNUlib data structures:
I will think about it.
