On Wed, 2003-05-28 at 00:01, kfogel@collab.net wrote:
> 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.
Really? Why? Right now, the two bits of information are always in
sync; we instruct delta_dirs to send a skeletal edit precisely when the
editor isn't going to request deltas anyway. I can't imagine any
situation where we wouldn't want them to be in sync. And if you did
accidentally feed a skeletal edit to a driver which wants text deltas,
something horrible would happen, like working copy corruption.
Unless there's a compelling reason for both parties to be in control of
a negotiation, it's usually simpler and less error-prone for one party
to make the decision unilaterally.
> 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.
That would be terrible. You'd get situations where code can work with
ra_local (or with ra_dav, because ra_dav is so divorced from the regular
API) but not with ra_svn. You'd have all this meaningless flexibility,
with the addition of a big fat land mine which will go off if you ever
use it.
> 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.
If the driver has to correctly guess what the editor's choice will be,
what value is there in giving the editor a choice?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 28 07:46:48 2003