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

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

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]