[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ozone and Apache XML database project?



Falko Braeutigam wrote:

> Joerg and all, as you know I'm a terrible bad list moderator and project
> coordinator. 

I don't get this impression.

> Please don't let statements as the above discourage you from
> jumping in! Sometimes I'm just to stupid honest.
> Yesterday I was very frustrated about the apache XML PMC. First they asked
> us to donate Prowler, then we did a lot of work to make it happen and now
> it seems that they don't actually want this or they are still busy with
> reorganizing or something else, I dont' know. 

It seems that Apache Cocoon's 'acting' package has much to do with a 
prowler-like datasource integration framework. To me this is just a 
workaround of the Cocoon developers to get some ad-hoc database functionality 
into Cocoon, and the ending point will be the need of a bigger Cocoon XML 
document transaction API (doesn't 'acting' mean 'transaction' in the end?). 
That's what Ozone's part in the game could be in the future. 

> This of course had nothing to
> do with ozone and your mail. It just got me frustrated about
> to-much-talk-and-to-less-action guys.

Falko, I don't mind. Please don't be frustated. To me, both Apache XML and 
Ozone DB/Prowler are great gifts. I like to work with all the sources and 
learned a lot. So I support both and will do my best. 

> Joerg, you _did_ already send a patch. Thanks for your help again. Of
> course my mail wasn't meant to offend you. I would be more than happy (!)
> to tackle the raised issues together with you and all the other guys in the
> list.

It was rather a small patch - I plan to submit more. I'm new to Ozone, so I 
will have to learn many things you might already have tackled, before i can 
contribute more valuable things. 

> You raised some issues in you mail. We already started to work on the new
> XML support. Lars has proposed a new architecture which I think is a very
> good strarting point. 

Where can I find more about Lars' proposal?

> IMO XML is the most important point currently. And it
> is a good point for others to jump in because we need a completely new
> concept, design and implementation. Should we start things by discussing
> the requirements and the concept of the new ozone/XML?

Of course the strength of Ozone is that both Java objects and XML are 
supported in a common persistency framework. I agree that we need a clean, 
sophisticated XML database architecture.

Falko, some further notes to your questions:

- Tomcat-like XML config: Tomcat got a 'conf/server.xml' which looks like the 
following :

---snip--------server.xml-------
  <Server port="8005" shutdown="SHUTDOWN" debug="0">
    <!-- Define the Tomcat Stand-Alone Service -->
    <Service name="Tomcat-Standalone">
      <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
      <Connector className="org.apache.catalina.connector.http.HttpConnector"
               port="8080" minProcessors="1" maxProcessors="75"
               acceptCount="10" debug="0">
      </Connector>
      <!-- Define an SSL HTTP/1.1 Connector on port 8443 -->
      <Connector className="org.apache.catalina.connector.http.HttpConnector"
               port="8443" minProcessors="1" maxProcessors="5"
	       acceptCount="5" debug="1" scheme="https" secure="true">
        <Factory
          algorithm="SunX509"
          className="org.apache.catalina.net.SSLServerSocketFactory"
          clientAuth="false"
          keystorePass="tomcat"
          keystoreType="JKS"
          protocol="TLS" />
      </Connector>

      <Engine name="Standalone" defaultHost="localhost" debug="0">

      <Logger className="org.apache.catalina.logger.FileLogger"
              prefix="catalina_log." suffix=".txt"
              timestamp="true"/>
[...]
----------snip----------

I think this configuration philosophy of "Servers", "Connectors" and 
"Engines" could also make sense to Ozone for setting up an extensible 
server/client architecture. Maybe an Ozone DB port protocol should be 
specified and other things could be done, to clarify the URL things such as 
"ozone:remote://...", "ozone:local://..." etc. which are rather an obscurity 
to me. Secure Ozone connections would be great in my opinion.

- DxLib and Java 2 collection framework: the Java 2 classes are able to work 
on multi-threaded environments with "Collections.synchronizedCollection()" 
calls. In order to keep the Java 2 Enumeration/Vector/Hashtable classes 
compatible with Java 1.1, theses classes are synchronized (and have improved 
remove() control), but have non-synchronized alternatives named 
ListIterator/ArrayList/HashMap. If are are more Ozone issues why the Java 2 
collection framework could not be used instead of DxLib classes, I would like 
to know more.

Jörg

-- 
Jörg Prante
Sevenval AG (HRB 32757) e-business marketing technologies
D-50667 Köln . Alter Markt 36-42
Fon +49 221 65007-0 . Fax 4249891
http://www.sevenval.de . joerg@7val.com