On Thu, 24 Jul 2003, Matthew J. Dovey wrote:
> > > The world has moved on from this model, IMO, and not being able to
> > > gracefully cope with large records is going to be an increasingly
> > > significant failing. -Everything- is going XML, for better or
> > > worse, and XML isn't a compact data format. Having to return only
> > > short metadata records is, again IMO, an extremely short sighted
> > > decision that will hinder take up worse than a single, optional,
> > > parameter that references a well defined, well understood and
> > > broadly implemented standard.
> > I couldn't have said it better myself.
> But I thought that Rob's raison d'etre for this xPath thing was that
> your client couldn't cope with servers returning large XML
> records(something about it blitzing mozilla off the map) ;-)
It's not the client, it's the computers that we (and by that I mean
everyone not me personally) want clients to be able to run on. This
/isn't/ Grid computing. We want to have 400 mHz machines running win98
and IE5 using simple SRU/XSLT clients. If they have to download 10 500kB+
records just to display the title and repository, they're going to choke.
Here's some others off the top of my head:
* Bandwidth isn't free. Ask Slashdot how much they pay for all that traffic.
* Clients can be simple to write. Servers will never be simple to write.
* The client knows what it wants. Why should the server have to take the
time/bandwidth to send the entire record.
* If a client can't handle a complete record in one go, currently they're
just out of luck. You can't page through a record without XPath.
> To come back to Mike's 'the half-dozen different user-communities Rob
> described in his last message (and no doubt others that we've not
> anticipated), When they come to us and ask "Is SRW suitable for our
> large-record databases?"'
> I'd like to answer "yes" too - but I'd prefer to be able to do so, so
> that they wo'n't then look at what we've done and say "very clever, but
> that doesn't actually solve our requirements. Never mind, we'll do our
> own thing".
That seems like a pretty hard ask ... to be able to solve requirements
before the community with the requirement comes to us. But I think that's
a good argument in favor of XPath, thanks :) As the only way to be able
to solve unknown requirements is to be flexible with a wide scope for how
requests can be handled within a standardised framework.
,'/:. Rob Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: telnet: nebmedes.o-r-g.org 7777
____/:::::::::::::. WWW: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I