You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by "Vladimir R. Bossicard" <vb...@yahoo.com> on 2002/12/05 09:56:49 UTC

[2.0] Shaking up the tree

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. 
Thanks.

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
organization:

- 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).

Thoughts?

-Vladimir


=====
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [2.0] Shaking up the tree

Posted by "Vladimir R. Bossicard" <vb...@yahoo.com>.
> First Vladimir, I just want to thank you for all your hard work and your 
> commitment to the project.

Thank you, thank you :-)

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

I fear that there will be too much redundancy in the code.  The code will be
split a little bit everywhere and will be hard to maintain.

maybe :

   - xmlrpc
       - client
       - server
       - service

would be easier to maintain.

-Vladimir

=====
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [2.0] Shaking up the tree

Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
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

Kevin


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. 
>Thanks.
>
>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
>organization:
>
>- 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).
>
>Thoughts?
>
>-Vladimir
>
>
>=====
>Vladimir R. Bossicard
>Apache Xindice - http://xml.apache.org/xindice
>
>__________________________________________________
>Do you Yahoo!?
>Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>http://mailplus.yahoo.com
>
>  
>