d at drobilla.net
Thu Feb 7 16:54:00 PST 2013
On Thu, 2013-02-07 at 19:13 -0200, Luis Henrique Fagundes wrote:
> Hi Everybody,
> I just released a pre-alpha version of python-lv2, a python library to
> extract structured data from LV2 ttl files. My main need is to have a JSON
> file with everything that's needed by my application. The lv2.rdfmodel is a
> general purpose library for modeling and extracting data from rdf files and
> may deserve to be a separated project.
Cool. A decent way of shipping descriptions over JSON would certainly
> The code is available at:
> The most interesting thing now is to check the general idea, I still have
> to model everything from LV2 specifications for it to get useful. Feedback
> is appreciated.
To be easy to use you will have to bake in some specifics I'm sure, but
you really want to avoid having to explicitly model everything in the
API, it's not extensible and means your interface will be restrictive.
For example, I don't think an AudioInputPort etc. class for every
possible port type is a good idea, just have a Port class which has
(several) types, i.e. directly reflect reality. You don't really win
anything that way, when in doubt make it general. Same goes for
vocabulary classes like Foaf, rdflib.Namespace already supports this
directly without having to list every "allowable" URI in the API.
I partially made this mistake with Lilv and regret it, some wrappers are
nice, but trying to explicitly wrap everything is an intractable mess
that ends up being more work for less power, and not really any clearer.
Don't get me wrong, more interfaces don't hurt and a nice Python
interface is great, this is just my advice borne from several years'
experience writing LV2 APIs. Properties are simple/extensible things,
exploit that simplicity and export it to your API users with minimal
cruft in the way wherever you can, or else your API gets in the way.
Also, could you please rename this? The name "lv2" is reserved by the
actual LV2 specification/package, and is not an appropriate name for
third party packages.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Devel