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
