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

Breno Costa wrote:

>Hi all,
>
>   Thanks for the replies. Unfortunately I cant help on this new
>project, as I'm not C++ fluent.
>
>    But I can make Debian/Ubuntu Linux packages for the software. I'm
>a member of the Ubuntu-BR project.
>
>cheers,
>
>-- Breno
>  
>
That would be great!
However,  the project is not language specific.  Most of the people will 
be uing java, and the idea
is to support many languages...

>On 6/23/05, Philipp Suter <[email protected]> wrote:
>  
>
>>Hi All
>>
>>I was discussing some of the mnetioned points with webhiker a few weeks
>>ago as we both are in the need of a xmldb server. Tom kindly offered his
>>help concerning the programming of the server. Our discussion was on the
>>xml mailing list under the topic "[bdbxml] How to avoid out of memory
>>errors with Sleepycat XML DB".
>>
>>Tom McCubbin wrote:
>>
>>    
>>
>>>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...
>>>      
>>>
>>which is the perfect implementation scenario from my point of view, here
>>are some benchmarks: http://www.cs.fsu.edu/~engelen/soapperformance.html
>>
>>    
>>
>>>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.
>>>      
>>>
>>Here is a quote from an email of the abovely mentioned discussion:
>>"One thing you might want to ponder on before you get started, and which
>>a quick perusal of the spec might not make immediately apparent, is that
>>Xml:DB is based on nestable Collections.
>>At fiest glance, the XmlContainer maps quite nicely onto Xml:DB
>>Collections, however, unlike Sleepycat, in which all containers are
>>flat, Xml:DB allows Collections to contain other Collections as well as
>>XML documents.
>>This might make translating the XQUery or XPath statements a bit more
>>tricky, since one needs to traverse child collections when evaluating
>>the expressions.
>>But perhaps you can use the metadata storage capabilities of Sleepcat to
>>store this info about relationships between Collections. "
>>
>>    
>>
>>>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 could test on windows and os x if anybody is interested in os x.
>>packaging is only possible for os x, I do not have any packaging tools
>>for windows.
>>
>>cheers
>>ph
>>
>>    
>>
>>>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]
>>>
>>>
>>>      
>>>



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