On Sunday, February 17, 2002, at 03:10 PM, Mark J. Stang wrote:
Kimbro, After reading Stefanos reply, I forgot to mention dynamic linking. I am currently doing it myself, but on the client side. That means that when my client makes a change I have to decide which Key + Path to update and apply the changes to the right document.
By dynamic linking, do you mean you're virtualizing everything to make it look like one big document?
So I guess I have a vested interest in being able to build documents
out of pieces, update/display/view the pieces and the whole, transparently.
I have put together a Publish/Subscribe XML Database using JMS, my version of a Query Language and Xindice. If the internal data changes, I need to be notified. So are there any plans on any kind of a CallBack mechanism? Except for one or two obscure relational
No plans but it's something I've been thinking a lot about. Basically it has to do with lightening what goes on in the database and pushing more logic out to the client. I'm thinking if you actually move larger chunks of data around less often and rely on subscriptions for changes you can build a better performing and more scalable overall database design. Basically, putting really intelligent caches into the application. They could seamlessly cache query results and document retrievals and dump their caches on notification of modification.
The database is reduced to doing just simple queries and modifications, no data manipulations beyond that, not even joins. It's more like LDAP then a RDBMS but given the nature of XML data and the applications that use it, it might actually work pretty well.
It would work well for an environment where you have one database and ten frontend app servers, not so well for one where you have a few thousand client applications connecting directly. Of course those clients should probably be talking to a middle tier anyway so put the ten app servers back in and it would help there too.
The key is the volatility of the data, low volatility would work great, high volatility not so great. Caching query results would be tricky in relation to document inserts, but I think there's some way you can optimize that.
databases, the only mechanism for detecting changes is polling. I added a layer around that to avoid the problem. It would be nice if there was someway for a client to be notified when the data changes.
Mark
Kimbro Staken wrote:
Anything in particular you're interested in?
On Saturday, February 16, 2002, at 01:05 PM, Mark J. Stang wrote:
Count me in.
Mark
Kimbro Staken wrote:
We need to get new development kick started here. To start I'm trying to
collect all the bits of information/features/ideas/questions into a
document for everyone to see. I've posted the start here
http://www.xindice.org/papers/planning.html
This is basically a brain dump of things that have been looked at/asked
for in the project. It isn't complete, but there's already a lot of stuff
there.
Number 1 on the list is "Critical to bring in more developers". This is
very important, if you're interested in getting involved here, now is the
time.
My plan for the immediate future is to continue filling in this outline
and to collect feedback and expand on the items. I know that right now it
probably isn't exactly clear what a lot of this stuff is, but I wanted to
get the general ideas down first and then expand and detail. There's a
LOT
missing so please help me fill it in.
Thanks
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
