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

"Mark R. Diggory" <mdiggory-Mahy8Y1M33PaZwrp7/[email protected]>
Newsgroups gmane.comp.db.dbxml.general
Message-ID <[email protected]>

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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.