Matt,
Starting with my own Server.   It talks to Xindice.   However, I am
going "embed" Xindice in my server so that I don't have the network
latency and the extra JVM hit.   I wrote a SQL like query language that
my clients use to talk to Xindice.   My server parses, runs the queries and
sends the responses.    It does all the XPath so the clients don't have to.
They do things like:

select customer from customers where lname starts with 'Stang'

Mark

Matt Liotta wrote:

> That is not a bad idea. Did you layer the JMS client for Xindice on top
> of its Java API or did you make an actual JMS API for Xindice?
>
> -Matt
>
> > -----Original Message-----
> > From: Mark J. Stang [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 12, 2002 12:24 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: replication
> >
> > I have been approaching the problem slightly differently.   Rather
> > than have my clients talk to Xindice directly, I have an intermediate
> > Server.  All of my clients are JMS clients, my "Xindice" server is
> > also a JMS client.   My clients subscribe to "documents".   My
> > plan for replication is to have another "JMS Client/Server" also
> > subscribe.   It listens for changes and updates Xindice silently
> > in the background.   If one dies, it steps up and takes over.
> >
> > Mark
> >
> > Matt Liotta wrote:
> >
> > > ic, I am currently generating globally unique identifiers for all
> > > documents no matter what collection they are in. This would of
> course
> > > all my application to make use of replication without fear of
> documents
> > > in different collections colliding. However, this wouldn't work for
> all
> > > applications, which is why I was suggesting the concatenation of the
> > > collection identifier with the document identifier.
> > >
> > > -Matt
> > >
> > > > -----Original Message-----
> > > > From: Sean Kelly [mailto:[EMAIL PROTECTED]
> > > > Sent: Wednesday, June 12, 2002 11:34 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: RE: replication
> > > >
> > > > > I thought Xindice only enforced unique document identifiers at
> the
> > > > > collection level. What's to stop someone from adding the same
> > > document
> > > > > uuid to another collection?
> > > >
> > > > Nothing.
> > > >
> > > > By virtue of joining the same peergroup, peers agree that the same
> ID
> > > for
> > > > a
> > > > document means the same document.  If two peers want the same ID
> to
> > > refer
> > > > to
> > > > different documents, they must belong to different peergroups.
> > > >
> > > > In other words, it's up to the peergroup to provide an ID policy
> and
> > > > mechanism.
> > > >
> > > > --
> > > > Sean Kelly
> > > > Independent Consultant
> > > > http://kelly.homeunix.com/
> >
> > --
> > Mark J Stang
> > Architect
> > Cybershop Systems

--
Mark J Stang
Architect
Cybershop Systems

begin:vcard 
n:Stang;Mark
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:Mark Stang
end:vcard

Reply via email to