Vladimir R. Bossicard wrote:

For a general admin tool I guess the webapp path is the best way to go.



And why not implementing a WebDav for Xindice?

We could use the Jakarta Slide project and it's remotely accessible, no need to
develop a specific client?

Just a thought

-Vladimir



True... I think thats a great idea as well.

On a similar note, I thought the idea behind the XMLDB api was to provide a generic communication protocol for working with Native XML Database contents thats independent of Vendor. Seems IDE's that would be pushing to develop "XMLDB" specific client tooling, and not "Xindice" specific tooling would be more successfull and have the widest audience. So, while writting a "Xindice plug-in" for Eclipse is neat, it seems too "narrow" in audience. Its like saying, "I'll write a MySQL plug-in for Eclipse, and I'll implement it in JDBC. Now, is it a MySQL plug-in or is it a JDBC plug-in thats just using the MySQL driver? Well, is it a Xindice plug-in or is it an XMLDB plug-in and just happens to be using the Xindice XML:DB driver?

So while, a plug-in for Eclipse is a neat idea, its audience is kinda limited if its just for Xindice. Something more fully featured might arise with a large developer audience if it were focused on the XMLDB aspect.

Couldn't the same be applied to WebDav? Should it be a WebDav service for Xindice, or a WebDav interface for an XMLDB Service that just happens to be the Xindice implementation?

-Mark







Reply via email to