cmpilato@collab.net writes:
> GACK! Use this one instead (the previous one launches a new browser window):
Thanks! I've updated
http://subversion.tigris.org/issues/show_bug.cgi?id=510
with this text:
--------------------8-<-------cut-here---------8-<-----------------------
Here are the details, from the relevant section of rev 2328 of
notes/STACK. Note that the concerns about editor composition no
longer apply:
Change #6: Move textdeltas to the "other side" of the editor.
STATUS: Being discussed on list; holding off on making this change.
The Way It Works Now:
The driver of an editor takes a source and target stream, puts them
together via svn_txdelta() to produce a stream of "windows". The
driver then pushes these windows at the editor's window-handler.
Proposed Change:
Move this process to the other side of the interface, into the
editor implementation, giving the editor the power to deal with the
source and target streams directly.
Specifically:
- remove the editor's apply_txdelta() routine
- create two new routines:
apply_delta (filebaton, [src_stream], target_stream)
set_file_contents (filebaton, [src_stream], delta,
enum delta_type)
apply_delta() sends svndiff deltas.
set_file_contents() can send plain text or other
types.
It becomes the obligation of the editor implementation to
implement at least one of these two routines; if one
routine is NULL, the driver must use the other.
Rationale:
It's too restrictive to force every editor implementation to accept
and deal with small svndiff windows. For example: Greg Stein wants
to send plain text while debugging his commit-editor and network
layer. It's best to allow the RA layer to make it's own choice
about how to break up the two streams most efficiently.
The reason [src_stream] is optional is that it may be NULL; this
presumably means that the editor already has access to the src
stream.
(Greg and Jim, did I get this explanation totally wrong? My notes
here aren't perfectly clear. Please elaborate if you need to.)
Problem:
Editor composition becomes more difficult if we use streams. A
window is a discrete chunk of data that can be used by several
consumers, but streams are different: if consumer A reads some
data off a stream, then when consumer B reads, she'll get
different results. You'd have to design your streams in a funky
way to make this not be a problem.
In some circumstances, this isn't an issue. After all, usually
a set of composed editors is a bunch of lightweight editors,
that don't do much, surrounding a core editor that does the real
work. For example, an editor that prints out filenames wrapped
with an editor that actually updates those files. In such
cases, the lightweight editor simply never reads data off the
stream, so the core editor is not deprived of anything.
But other editors (say, a commit guard?) might want to actually
examine file data. That could have bad consequences if we
switch from windows to streams.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 24 20:20:25 2002