Hi all,
We've been using BaseX for several years now and have constantly been skirting around our primary use case: using BaseX in an embedded mode. What I mean by this is using BaseX in-process in an application without running any kind of client/server communication bridge and with very direct access to BaseX primitives. There are several reasons for wanting to do this including performance (which seems to be the subject of recent discussions, I.e., running the server in "local" mode). My own primary reason is to gain more direct access to the database objects. For example, we routinely have a need to:
- Directly access and traverse database nodes by climbing, descending, following, etc. - Insert or remove content at a specific database node - Store references to individual nodes (I.e., using its "pre" and "index" value) - Fine-tune queries in order to set context, external functions, etc.
While many of these operations can indeed be performed through the existing client/server interface, it's less friendly - especially when doing things like asking for the next sibling of a given node. With a direct embedded API you just get the next node, bypassing the XQuery processor altogether. From my current work in this area, I think BaseX is already "primed" for this kind of API - 90% or more of the code is already in place since most of the primitives already expose common methods for use by database commands, XQuery processor, etc. All that should be needed is to expose this functionality in a stable and complete API.
Good examples of applications that may need this kind of API include media players (I.e., for storage of the media library data), simple stand-alone database applications, etc. Until recently, we've been able to adapt BaseX to fit our needs by writing a thin wrapper layer that interfaces with the appropriate BaseX classes. However, with the rapid pace of BaseX development these days it's becoming increasingly difficult to track each release since we rely on aspects of the BaseX codebase that are not really intended for public consumption and thus keep changing. This brings up a couple questions:
- Are we the only ones interested in a direct embedded interface? - Does the BaseX team have any plans to implement such an interface? - Would such an interface be better implemented by the BaseX team (as opposed to a third party)?
I don't mind doing some work in this area, however, I have some concerns about doing so. Primarily, given that the whole idea would be to make direct integration easier and more stable it seems like the structure and layout of the classes in the embedded API and the ways that they interact with the underlying BaseX objects should probably be determined by the BaseX team. The danger is that someone outside the team spends effort creating such an interface only to do things in a way that's either not preferred or difficult to maintain as the core team continues to improve the overall product.
Hopefully this was clear... Thoughts?
Dave