Hi Daniel, all!
This -- problems with compiling -- reminds me of a task I've been
thinking about for a while but haven't got time to fully elaborate on.
How do you feel about modularizing RDFLib into a couple of eggs? Using
the namespace mechanism of setuptools, this can be quite convenient.
Zope 3 is a good example of a successful practise, as is e.g. the
partition of Paste.
I just paste my non-finsished suggestion here as a food for thought:
* RDFLibCore
- perhaps using entry points for registering added (and 3rd party)
plugins using the setuptools/egg mechanism
- for:
syntax
backends
query engines (probably also possible to dispatch directly
to backend impls)
* RDFLibBackends
- all of mysql, bsddb, redland etc.
- or even split into embedded and relational or similar?
- registered as plugins using the setuptools/egg mechanism
* RDFLibSparql
One reason is to make it more pluggable and lightweight, and also to
keep the core of RDFLib in pure python.
And this not only to make it installable without compilation, but also
to faciliate use with Jython, IronPython and other python ports (with
possible backends like Jena et al). Also, having separate packages
could make development smoother (running tests, refactoring etc).
The pluggable architecture could if possible not *depend* on
setuptools, but use it if available. So the internal plugin registry
can be the same as today (used by setuptools if there or perhaps by
"manual" glue code if not..). Though practically it could be easier to
accept the setuptools dependency and "egg orientation" -- and I
suspect the namespace mechanism requires it.. (Note that the rdflib
namespace would be for project-owned code only (the "partitioned"
rdflib); 3rd party stuff can use the entry-point mechanism but should
have their own top-level package names.)
Does this sound interesting or too far-fetched from a practical
perspective? I *believe* it can be done without a gargantuan effort.
(I don't know what impact it will have on e.g. the debian rdflib
package and similar though..) It is perhaps a thing for RDFLib 3..
Best regards,
Niklas
_______________________________________________
Dev mailing list
Dev@rdflib.net
http://rdflib.net/mailman/listinfo/dev
