On Mon, 20 Dec 2004, Adam Dickmeiss wrote:
> Dr Robert Sanderson wrote:
>> * Most communities will decide internally on a profile of usage for the
>> protocol. That profile will determine at the very least SRU vs SRW.
> Profiling the way to get hold of Explain and the transport is not my cup
> of tea.
But it's already happening by dint of implementation. Because the
protocol doesn't specify that you -have- to implement SRW, people aren't
implementing it.
If I have an SRW only client, I'm not going to be able to interop with the
SRU only servers out there today. That's just the way of it.
>> Therefore, most client developers will develop clients for the needs of
>> their community. Their community wil have already established one or more
>> Therefore, there won't be a significant run-time requirement for polling
>> how to talk to the server, for most client developers.
>> * Simple cross-community clients will only use SRU.
>> * Such clients thus have no need to poll.
> That's the way things are moving to. Before when all servers implemented
> Both SRW and SRU there was a clear choice for developers. Not any more.
I don't follow. The choice is:
SRW
SRU + SRU/POST
SRU + SRW
SRU + SRW + SRU/POST
How is this any different for getting the explain record than today? You
use SRU, if that doesn't work (1% of the time) you try SRW or give up.
Unless you're proposing that people will implement SRU/POST and not SRU/GET?!
> It is more much complicated that a client will have to support all the
> transports out there.
If it's hard to switch from using GET to using POST for form submission,
get a new toolkit.
>> By introducing the option, we only add a slight burden to the clients that
>> are already complicated to write, and the servers who wish to support it,
>> which are already complicated to write.
> We have effectlive moved all the transport logic to clients.
The clients have no additional logic beyond what they have today, because
SRU/POST will never ever be implemented without SRU/GET.
> We have moved the extra work to profiling ... They will have to mandate
> one transport.
No they won't. They can mandate multiple transports all they like.
>> Most of us have implemented SRW servers, but it's easier to write
>> braindead clients for SRU. To date, no one (to my knowledge) has written
>> a particularly advanced client.
> Well, so far clinets could be braindead. All servers supported SRU. But
> if some servers say only support SRW, those braindead clients will not
> work. Similarly when using some SOAP "only" toolkit, it is a problem to
> work with SRU. (For example gSOAP does not do SRU).
We have that issue today. Adding SRU/POST doesn't change it at all.
Most simple clients will use SRU. Clever clients will switch between SRU
and SRW as and when required.
>> Almost correct. I don't think that clients will have to poll, so I don't
>> think it's problematic because it's a non issue for 95% of clients. See
>> above :)
> Those 5% tend to take most of the time. It's a great burden for client
> tools that they have to support all transports out there.
It's somewhat of a burden for 5% of all clients. And it's the same burden
that we have today.
Rob
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Dept. of Computer Science, Room 805
,'---/::::::::::. University of Liverpool
____/:::::::::::::. L5R Shop: http://www.cardsnotwords.com/
I L L U M I N A T I
