xml-xindice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Ross <Kevin.R...@iVerticalLeap.com>
Subject Re: [2.0] Shaking up the tree
Date Thu, 05 Dec 2002 14:04:12 GMT
First Vladimir, I just want to thank you for all your hard work and your 
commitment to the project.

I disagree that Xindice is not a server anymore...I know what you mean 
by that...it is no longer standalone and has definitely changed, but I 
think the client vs. server packages are still relevant.  When you ask 
someone what an 'accessor' is, then ask what a 'client' is,   I think 
you'll find that people are more likely to understand the intent of 
calling it a client.  

-'client' is relevant because it is usually the external way to access 
the database (whether in-process or out-of-process)
-'server' is (may) be relevant since this code does still serve xml.

As far as admin goes, I believe there is (using current terminology) 
both a client and a server side component, so my vote is to place the 
relevant pieces under those heirarchies, or even further down (i.e. on 
the client, I believe that it is xmlrpc based).

my vote, to take the refactoring a little further, this makes even more 
sense to me.

- xindice
     - core // all real code not interfacing with outside protocols goes here.
          - admin (Kurt's admin tool) // the heart of the admin code

     - service
          - xmlrpc
              - admin (Kurt's admin tool) // xmlrpc service or listener or dispatcher whatever
term you like
          - soap
              - admin (Kurt's admin tool) // soap service or listener or dispatcher whatever
term you like
     - client
          - xmlrpc
              - admin (Kurt's admin tool) // xmlrpc admin client
              - message
          - embed
          - soap
              - admin (Kurt's admin tool) // soap admin client
     - util

This is just what makes sense to me.  I commonly use the service 
component pattern, where the client -> service -> core, especially when 
the use of multiple protocols is necessary.  This structure allows a 
great deal of lattitude for adding new components and transport 
mechanisms to the existing package structure.  

my 2 cents


Vladimir R. Bossicard wrote:

>Hi all,
>I suddenly can't send email from my other webmail
>account, so I will temporarly use my yahoo address. 
>But use "vladimir@apache.org" or
>"vladimir@bossicard.com" to sent me private emails. 
>Anyway, I've been thinking of 2.0 these days and since
>we can affort to break users' code (I assume), let's
>shake the tree. :-)
>Xindice is not a server anymore but this aspect is
>still present in the packages: xindice.client and
>xindice.server.  Xindice is providing an XML database
>and accessors (implementing the xmldb framework) to
>handle the database.  So why not having the following
>- xindice
>     - admin (Kurt's admin tool)
>     - core
>     - accessor
>          - xmlrpc
>              - message
>          - embed (*)
>          - ... (like SOAP, WebDAV...)
>     - util
>(*) I do not particularly like the name "embed"
>because it denotes a usage and not a technology but I
>couldn't find a really better name.
>How the different accessors are defined is not
>Xindice's problem.  Some implement a client/server
>solution (xmlrpc) other not (embed).
>Vladimir R. Bossicard
>Apache Xindice - http://xml.apache.org/xindice
>Do you Yahoo!?
>Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

View raw message