Re: [bdbxml] Developing a local (Swing) front-end

I'm fairly sure the java client to BDBXML is using swig to punch through 
the JNI to get at the c++ library.  Hence some of the dispose/memory 
issues i've seen on the list.  I'm all for any and all server 
implementations, and client implementations, and much more focused on 
the protocol and the service definition.  I have used the axis toolkit 
both in java, and c++, though it was ~ a year ago.  We did benchmarks, 
and both lost out in all tests by a magnitude or better to the gsoap 
implementation.  gsoap is also much less obtrusive in deployment from a 
c++ perspective, as it basically scan's a header file, and generates all 
the code for your service objects.  Clients don't have to use gsoap.  
e.g., you could roll a client in pure java using the java axis kit.  We 
did just this w/ a java portal that was talking to the gsoap server...

Finally, the deployment of the c++ server is a simple single binary w/ 
few dependancies, and very lightweight.

In any case, i think of it more like jabber.  Define a dialect of xml, 
behavior, context, rules, etc., and then deploy some test 
implementations.  We can recut the code in all sorts of languages.  I 
know most people don't like c++, and for good reason.  It is not a 
language for the masses...

More importantly, I am clueless re: the XML:DB stuff, and will go off 
their spec.  Is there something else we should apply that is missing 
from that spec?  That's what we should really focus on...do we want 
their spec solely, a subset plus our extensions, or maybe a superset of 
core 1 plus our extensions?  I would like feedback here, because my only 
use to date w/ xml is in configuration files / systems.  This hasn't 
warranted BDBXML, but i am evaluating for just that reason.   All of my 
config queries are in XPath, and I would love to have an optimal 
centralized configuration system such as this.  Currently, i can keep 
shared config info on a server, and access the config using XInclude 
from a local config file.  It would be nicer for me to keep all config 
docs in one location, and have decentralized processes seemlessly, and 
quickly accessing their configuration info...

I'll get the server done by weeks end i hope...

My last ? is what platform people would want a pkg for.  I'm doing the 
dev work on linux x86, but also have a sparc solaris workstation, and 
windoze machines...feedback from those interested in testing...

i'll try and send another email to all involved, because sleepycat might 
want us to take this off list...i don't know.

-tom

Mark R. Diggory wrote:

>
>
> Tom McCubbin wrote:
>
>> Yup.  It was the initial hope to expose an API that could support 
>> XML:DB core level 1.  I am going to expose sufficient functionality 
>> to allow
>> java clients to provide a light weight wrapper that would be the 
>> XML:DB driver.  I am similarly overtasked, but hope to have a server 
>> up and running
>> shortly.  I looked into xml/rpc long ago, before the SOAP spec had 
>> started to formalize.  It is much more approachable, but i think not 
>> as cross-
>> language friendly going fwd.  Maybe I'm wrong.  From a c++ 
>> standpoint, there are no products that approach the performance of 
>> gsoap, and
>> understandably because it uses a pre-processor / code generator to 
>> create compile time marshal/demarshallers.  No runtime parser is 
>> going to
>> approach it.
>
>
> Well, this is the tack that eXist took, there is a primary eXist API 
> on the server side that exposes services on xml-rpc, soap, Web-Dav, 
> XML:DB, REST, etc.They are Servlet API implementations, all of which 
> can run on any standard Servlet Container (Tomcat, Jetty, etc). These 
> are all just services, the ultimate goal of which is to interact with 
> the eXist API (a B-Tree implementation in Java based on the original 
> XMLDB reference implementation).
>
> eXist implements XQuery using an implementation/approach similar to 
> Michael Kay's Saxon  XSLT transformer package on its own B-Tree 
> implementation. There was once a time that eXist could run on 
> databases like Berkeley DB, but they eventually just focused in on a 
> java based solution because of issues with maintaining query 
> capabilities over very different disparate external datastore 
> technologies. However, given this, I still think eXist could still be 
> extended to be backed by something like BDBXML.
>
>>
>> That said, we can easily support native JNI access to the gsoap 
>> client, or use a java-pure toolkit.  I'm not in a possition to be 
>> fanatical...I'm happy
>> to do the swig work to punch through the runtime.  whatever.
>>
>
> Doesn't the existing BDBXML Java client provide enough access 
> capability to adapt a soap interface to? Then instead of generating 
> (un)marshallers in C++ and Java, you just use Java, use XML-RPC/Soap 
> api's from Apache and run on any Java Servlet Engine. Not that 
> generating XML-RPC/SOAP servers in C++ etc wouldn't be usefull too, it 
> would.
>
> http://ws.apache.org/axis/
>
>> talk is just talk...so let me see if i can't proceed and you, and the 
>> others can test it out, help me to improve it, and we may just have 
>> something.
>
>
> We have a strong need for this sort of technology on out project.
>
>> i'll send an email to you, and the others just so i can get everyones 
>> name straight, and on a mail list...
>>
>
> Please do.
>
>>
>> ps - i use eclipse for my c++ dev work, and would love to have an 
>> addin that exercised the xmldb server...that would be cool.  Finally, 
>> the new
>> native eclipse on fedora core 4 is pretty impressive.  Seems to be 
>> much snappier...
>
>
> yes, the GNU GCJ work that Redhat/Fedora is doing is really making 
> Java a strong linux application platform.-Mark
>
> -Mark
>
>> Mark R. Diggory wrote:
>>
>>> I see this discussion and come back to the opinion that this is what 
>>> the XMLDB api is really tuned to (http://xmldb-org.sourceforge.net). 
>>> Basically, providing an API in Java for which drivers (analogous to 
>>> JDBC) can be developed. There are already examples of Drivers that 
>>> use XMLRPC for communication available if you review the eXist and 
>>> Xindice codebases. Ultimately both support embedded and remote db 
>>> instances. XMLDB in exist is delivered using standard XML-RPC and 
>>> Servlet API's, so theres no reinvention there and it represents a 
>>> good example for more native tooling. Theres no reason the same sort 
>>> of remote server interface couldn't be delivered using C/C++ or 
>>> whatever.
>>>
>>> This is elegant in that the XMLDB api already has hooks for 
>>> extensions such as XQueryServices, XPath services which are 
>>> considered Core functionality,  and any driver can implement 
>>> extended services on their db, for instance eXist provides an 
>>> UserManagement service thats built into its implementation.
>>>
>>> I've been working on two little projects at the moment:
>>>
>>> 1.) A very generic XMLDB browser/manager for Eclipse/Java based 
>>> somewhat on the Attrezzo Per Xindice 
>>> (http://attrezzo.sourceforge.net/)which is an XMLDB based Eclipse 
>>> Perspective that is dependent on Xindice.
>>>
>>> 2.) an XMLDB client to interact with embedded bdbxml instances for 
>>> the above manager.
>>>
>>> I have very very limited time for both these projects at the moment 
>>> and havn't yet released any of my development.
>>>
>>> IMHO BDBXML really needs an XMLDB API Client/Service implementation 
>>> (even if its a separate project external to BDBXML). There are 
>>> communities of OpenSource tools (Apache XML, Apache Cocoon, Spring 
>>> etc) that are using XMLDB as means to provide Generic Sources of XML 
>>> data to webapplications.  Implement even just an embedded XMLDB 
>>> client using the BDBXML java api and BDBXML becomes very attractive 
>>> in those markets.
>>>
>>> -Mark
>>>
>>> Tom McCubbin wrote:
>>>
>>>> FIRST, I (and the 'others') are totally unconnected to Sleepycat, 
>>>> or any official anything in regard to DBXML.
>>>>
>>>> That said, there was recently an issue w/ this very topic brought 
>>>> up ~1 month ago.  We decided to put together
>>>> a client/server layer that would extend DBXML for this purpose.  A 
>>>> thin layer to issue XPath, XQuery stuff,
>>>> etc.
>>>>
>>>> I am currently putting together the server side of things in C++, 
>>>> while others will be making the java
>>>> client package.  For iter #1, it will be embedded in SOAP 
>>>> transactions, and details above and beyond
>>>> are still congealing.
>>>>
>>>> So, it this is for work, don't wait for us.  If this is production, 
>>>> don't wait for us.  If you want to join us in our
>>>> mad adventure, i'm sure you'd be welcome.  However, it'd be great 
>>>> if i wasn't the only c++ guy, as
>>>> i haven't a clue re: the nitty gritty details of win32, or the 
>>>> development platform, as my work is predominantly
>>>> focused on solaris/sparc, and now growing slowly more onto linux x86.
>>>>
>>>> That being sad, I have used dev-cpp/gcc on the win platform, and it 
>>>> makes us unix people feel much more at
>>>> ease.  I imagine most use the MS VisualXXX stuff though, and i am 
>>>> clueless.  It is so easy, i just don't get it:)
>>>>
>>>> -tom
>>>>
>>>> Breno Costa wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>    I was developing a Web-based interface for acessing BDB XML
>>>>> containers, but now I need to switch to a swing-based desktop app.
>>>>>
>>>>>   I'm just worried on network access of the containers, as BDB XML is
>>>>> embedded and has no servers. Network shares are an obvious solution
>>>>> but I dont think it's the best.
>>>>>
>>>>>    Has anyone ever been in this same situation?
>>>>>
>>>>> thanks,
>>>>>
>>>>> -- Breno
>>>>>
>>>>>
>>>>> ------------------------------------------
>>>>> To remove yourself from this list, send an
>>>>> email to [email protected]
>>>>>  
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------
>>>> To remove yourself from this list, send an
>>>> email to [email protected]
>>>>
>>>
>>>
>>> ------------------------------------------
>>> To remove yourself from this list, send an
>>> email to [email protected]
>>
>>
>>
>>
>>
>>
>> ------------------------------------------
>> To remove yourself from this list, send an
>> email to [email protected]
>>



------------------------------------------
To remove yourself from this list, send an
email to [email protected]