Fwd: [Clam-devel] CLAM and NASPRO

[Pau Arumi]

>> There may be however some downsides in doing this last thing (you'll
>> tell me): dependencies and, consequently, adoption.
ups... i forgot to comment on dependencies.

as stated in the plugin-related-task-list we want to make all
processing-objects dynamically loadable (aka plugins). processing
objects are the ones that typically depends on external libs (i.e. fftw,
libsndfile). thus, leaving a tiny libclam_core lib with only the generic
infrastructure (networks, network-players, plugins hosts, processing
infraestructure and such) that means basically no dependencies with
other libs nor processing algorithms.

well, to be exact networ-players have its back-ends (jack, portaudio,
ladspa...) with its dependencies. but you can avoid back-end
dependencies with configure options. (or should we make back-ends also
plugin based?)

anyhow i think you see the goal is to have a small "core" that can be
easily used in many different invironments. and easily extended through
other clam libraries and plugins.

>
> about python, we xavier said we want do clam python-enabled. but i don't
> see clearly how this fit with the plugins area.
too quick clicking "send". i meant:
"as xavier said, we want to make clam python-enabled."

p.