Joel Rosi-Schwartz wrote:
> "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. > > > > 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 > > 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. > > I must admit upfront that architecturally I am rather opinionated in this > area, so > you may want to take my thoughts with an appropriate measure of salt. > > There comes a time when a cleanly defined system starts crossing the line and > taking on services that are already provided more appropriately in other > quarters. > Imbedding callbacks in the database seems to me have crossed that line. J2EE > defines a rather clean model for implementing this use case. Put a service > bean or > two in place and pass *all* modifications to the data through the server. > Client > notification then is moved out to the server were it can (and has been) > implemented in a generic fashion. With low cost or free J2EE servers like > Jboss > available there is little reason to avoid them once the initial learning > curve is > paid up. > I don't know if I agree or disagree. I agree that we should maintain the encapsulation. And not crossing the border between "products". However, I have always felt that it is a MAJOR drawback, that Relational DBs don't have any way of notifying their clients without polling. And if you take a look at EJBs one problem with their performance is that without going out and retrieving the data, they can't tell if the data has changed. They do an enormous amount of re-reading data just to be sure that is hasn't changed. Precisely because there are other users of the data. Have we not moved past the 80's technology of client-server? I have a complete implementation of JBoss running as part of my customer installation. I don't use EJBs, they don't talk to Xindice. If they did how would the EJB server know if I had modified a document? The only way was to ask for last time modified and check to see if it "might" be different. And if it has, then what? Do you overlay the changes anyway, last in wins? Or do you tell your current client, data changed, do you want to overlay someone elses changes or abandon yours? Or do you just lock the document? And while someone is typing in a large document, someone goes in and deletes their tag. Now the person typing for an hour says save, but XPath can't because it can't find the tag? Sorry for running off at the mouth for so long. I guess I am opinionated also :-). - mark > > - joel > > > 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/ > > > >
