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