[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 510] New - invert txdelta interface ("change #6")
From:       issues () subversion ! tigris ! org
Date:       2002-09-24 18:17:24
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=510

*** Old
--- New
***************
*** 0 ****
--- 1,92 ----
+ +============================================================================+
+ | invert txdelta interface ("change #6")                                     |
+ +----------------------------------------------------------------------------+
+ |      Issue #: 510                       Component: subversion              |
+ |       Status: NEW                         Version: current                 |
+ |   Resolution:                            Platform: Other                   |
+ |   Issue type: TASK                     OS/Version: other                   |
+ |     Priority: P4                     Subcomponent: src                     |
+ +----------------------------------------------------------------------------+
+ |  Assigned To: issues@subversion                                            |
+ |  Reported By: sussman                                                      |
+ |      CC list: Cc:                                                          |
+ +----------------------------------------------------------------------------+
+ |    Milestone: TargetMilestone: Post-1.0                                    |
+ |          URL:                                                              |
+ | Dependencies: OtherIssuesDependingOnThis: 511                              |
+ +============================================================================+
+ |                              DESCRIPTION                                   |
+ gstein has wanted to do this forever.
+ 
+ ------- Additional Comments From sussman@tigris.org  2001-10-04 10:42 PDT -------
+ estimate 2 days, assign to gstein.
+ 
+ ------- Additional Comments From sussman@tigris.org  2001-10-04 13:47 PDT -------
+ assign to post-1.0
+ 
+ ------- Additional Comments From kfogel@tigris.org  2002-09-24 11:17 PDT -------
+ 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.
+ 

[prev in list] [next in list] [prev in thread] [next in thread]