Greg Hudson <ghudson@MIT.EDU> writes:
> The provider makes the apply_textdelta call, which is sent over the
> network to the consumer. The consumer receives the call; it may or may
> not decide it wants the text delta. We have to communicate that
> information back to the driver before we can start sending windows:
>
> P -----------> C apply_textdelta
> P <----------- C I {want/don't want} windows
> P -----------> C windows
>
> That's an extra round trip for each file. Why should this bit of
> information be negotiated on a per-file basis when no editor could
> possibly want to make the decision differently for different files?
>
> If, instead, we rely on the provider to "just know" whether or not to do
> a skeletal edit, then there is no need for a round trip:
>
> P -----------> C apply_textdelta
> P -----------> C windows (or none, for a skeletal edit)
>
> Have I achieved clarity?
Yes, eminently, thank you.
The current API allows for two situations:
1. A driver who is prepared to send text deltas if requested,
driving an editor who never requests them.
2. A driver who won't send text deltas, driving an editor who might
request them (and get a single null window in response).
It feels right to me that we support both. An editor can signal that
it doesn't want text deltas (even if you have them), and a driver can
signal that it won't supply text deltas (even if you could have used
them).
Is there any way to avoid the round trip without changing the editor
API itself? For example, your second exchange could become the
standard
P -----------> C apply_textdelta
P -----------> C windows (or none, for a skeletal edit)
...but on the Consumer side, what would really happen is this:
If receive a single NULL window, then feed it to the
window handler if any, else just toss it if no window
handler. But if receive real windows, then feed them
to the window handler, or error if no handler.
In this scheme, the driver has to have some more expectations about
what the editor will want -- but that would be true anyway if we got
rid of the mechanism by which the editor signals its preferences.
In other words, instead of changing the API, why not just change how
the API is marshalled over the wire?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 28 06:44:32 2003