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
- utilThis 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 "[EMAIL PROTECTED]" or
"[EMAIL PROTECTED]" 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
