I see in the source code that you are working on user/group security and
read and write access. One powerful feature would be to add xpath based
security. By allowing a user or group read/write access to a specific
xpath in a collection or document.
<person>
<name>John Doe</name>
<salary>1000</salary> <- no access
</person>
---- not real - access xml doc ---
<group>
<user id="bigboss">
<access>
<collection id="documents">
<xpath>//salary</xpath>
<privileges>none</privileges>
</collection>
</access>
</user>
</group>
This is just a quick example - an a final suggestion.
What do you think?
Regards, Niels Peter
On tisdag, januari 15, 2002, at 03:58 , Kimbro Staken wrote:
On Monday, January 14, 2002, at 03:31 PM, Chad La Joie wrote:
Well here are the lists of things I'd kind of like to see from Xindice
1. Lose CORBA, or at least give an alternative. I haven't taken an
in depth look at the code yet, but it seems that the CORBA interface
to the system is tightly coupled with the actual server. It seems to
me that breaking this coupling would make it easier to create some
other interfaces, like a SOAP interface.
XML-RPC is already available as an alternative. In reality there is no
tight coupling between the server and CORBA. It's very easy to add
whatever other protocol that you want. Where there is a tight coupling
right now is between the XML:DB API implementation and CORBA. That
doesn't prevent other protocols from being added, it just makes it
difficult to completely get rid of CORBA. Getting rid of CORBA is
something we've wanted to do for a while.
2. Consider using the W3C XQuery recommendation in addition to the
XPath support you already have.
Just to be picky I have to say, what XQuery recommendation? :-) XQuery
is still very much a working draft and will be for a while. We're of
course planning to support it and there has been a bit more discussion
about really getting going on it lately. We really need someone to step
up and take ownership for the project.
3. Consider allowing a XML Schema or DTD to loaded into DB so that
system could automatically type check entries. You could also might
be able to use this to help with optimizing indexing (not sure how,
it's just a thought).
There's been a lot of discussion lately about this too. We've always
planned to add XML Schema support eventually. Right now most of the
discussion has been around what Schema languages to support and at what
level in the server. Again we really need someone to take ownership of
this to really get it moving.
4. Consider some sort of authorization system. For instance, jsmith
can view these collections of these databases, but nothing else.
The same thing applies here, been planned for a while and in this case
there is even some code around but it isn't finished.
I'd be happy to help with 1 and 4.
Great, for 1 take a look at these projects.
http://www.xmldatabases.org/projects/dbXML-XMLRPC/
http://sourceforge.net/projects/xindice-xmlrpc/ - This will replace
dbXML-XMLRPC and update it for Xindice
http://notdotnet.org/
All of these are outside the core Xindice project, but I expect the
work to be rolled back in eventually. We wanted to experiment a bit.
For 4 take a look at the source in org.apache.xindice.core.security. We
don't need to keep any of that code, but it's worth looking at as a
starting point. One of the main reasons I never finished the initial
security system is that I wanted to make sure security was carefully
considered. Now that there are more eyes looking at the code it's a
good time to start to dig into the security framework. Yet again, we
need someone to take ownership of it.
Chad La Joie "It is true that you never know
what
Middleware Services you have until it is gone, but it
is also
IS&C - Virginia Tech true that you never know what
you've
been missing until it
arrives."
Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/
