Kimbro Staken wrote:
> 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 model of multiple front end app servers is perfect. But why do you feel the need for callback notification? This is what clustering technology in the app server already solves very nicely. In another thread I championed a disciplined approach to the architecture, this is simply an extension thereof with multiple servers. > 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/ > >>> > >
begin:vcard n:Rosi-Schwartz;Joel tel;fax:+44 1435 831011 tel;home:+44 1435 831010 tel;work:+44 1435 831010 x-mozilla-html:TRUE org:Techne Research Limited version:2.1 email;internet:[EMAIL PROTECTED] title:Architect adr;quoted-printable:;;Downgate Farmhouse=0D=0AFurnace Lane;Warbleton near Heathfield;East Sussex;TN21 9AZ;United Kingdom fn:Joel Rosi-Schwartz end:vcard
