>From IRC, a discussion of these aspects of current version of Ev2:
- add_file() specifies the properties but leaves the text to be
specified in a separate call, and a separate set_props() call exists but
is not used for this action;
- add_dir() specifies the children to make sure the directory is in
some sense "complete" right away, but there is no such notion when
modifying an existing dir;
- some calls are complete in themselves and others are pairs (or
triples).
<julianf> heh. Another Ev2 question.
<gstein> sure. shoot!
<julianf> See you want edit ops to be self-contained. But then there's
some "pairs" of ops, like (?) add-file, set-file-text.
<julianf> Why not just include file-text and file-props in every
add-file or mod-file operation?
<gstein> julianf: yes. there are exactly 3 pairs.
<julianf> Then there neen be no special case "pairs" (I use quotes
because I think at least one of them is a triplet).
<gstein> add_file()/set_text() could conceivably be one,
<gstein> then you have the set_props() followed by set_target or
set_text,
<gstein> as the three,
<gstein> so you could define some variants of those combinations,
<gstein> effectively expanding the API to encompass all combinations,
<julianf> (To me, text and props have equal importance, so including one
in the add-file call and not the other seems odd.)
<gstein> but I preferred to have limited combinations, and zero
functional overlap
<julianf> Hold on, combinations? A file always has text and props.
(Either could be empty but that's irrelevant.)
<gstein> both do not always change
<julianf> AH-HAH! "Change"!
<julianf> So what?
<gstein> set_props() applies to all node types
<gstein> to unravel the combinatorics,
<gstein> you'd need: set_dir_props(), set_file_props(), and
set_symlink_props(),
<julianf> (I don't want to unravel the combin.) OK, perhaps it's just a
matter of taste. Do we design
<gstein> tho the names wouldn't really be about props, but more about
"set stuff on a dir/file/symlink"
<julianf> Do we design "when you touch a file, always specify its
complete content (text & props)",
<gstein> that *is* a fair question,
<gstein> and I did not approach it that way
<julianf> or do we design "You can touch the text if you want. (Supply
the complete text.) You can touch the props if you want (supply the
complete props)."
<gstein> one other concern,
<gstein> which may actually be an artifact of the implementation,
<gstein> is that systemically, we would like to defer set_text() calls
until "the end"
<julianf> But what looks odd to me is, in add_file, the file's text and
props must both be specified, but props is in the add_file call and text
is in a separate call.
<gstein> ie. defer bulk data in case a problem occurs early, and/or
during the earlier steps we discover another source for the bulk data
<gstein> understood. setting the text also involves the checksum. that
would need to be pulled up, too.
<julianf> (FYI I'm reading notes/editor-v2.txt, not the header file, in
case they differ.)
<gstein> notes is more conceptual, so that's just fine
<gstein> I haven't vetted the header, so that may be more of Neels'
thoughts ;-)
<gstein> (tho I did update/"fix" the overview in the header)
<julianf> Conceptually, the set of props could have a checksum too. Or
the "whole content" (text and props together) could have the checksum.
Want to be pure? :-)
<julianf> Sorry if this is just flashing ideas around but I did want to
let you know the thoughts.
<gstein> we are nowhere close to applying a checksum to props
<gstein> so while that may be theoretically true,
<gstein> I see zero paths to getting there
<gstein> that is: we have *way* more tooling to do for that, than our
current desire to switch from md5 to sha1 for checksums
<julianf> Checksums on props is just a blue-sky idea to illustrate a
focus on concepts. Main immediate yellow flag is that props are sent in
two different ways: through "set_props" call versus through params in
add_file, add_dir, etc. Would be nice to have just one way. I think that
would facilitate writing stream validators, manipulators, and even
ordinary drivers and receivers.
<julianf> Perhaps remove "props" params from the add_xxx calls and
require set_props to be called as well as set_text.
<gstein> that is a possibility, yet opens up more combinatorics
<gstein> if anything, I might go with your unraveling. "want to change a
symlink? set props and target. one call."
<gstein> and then maybe add props to the set_text() ... or more like:
alter_file(...),
<gstein> and lastly renaming set_props() to set_dir_props(), since the
file/symlink case are then handled elsewhere
<gstein> oh. maybe add contents to add_file()
<julianf> Requiring a separate set_props would increase combinations of
sequences of calls, did you mean?
<gstein> yes
<gstein> add_direcdtory() would now become two
<julianf> three: add-dir, set_props, set_children :-)
<gstein> heh
<julianf> sorry, you want to go to one-call-per-op, and that's fine and
good.
<gstein> no... set_children() would never be called independently.
instead, further add/delete/copy/move would be altering children.
<gstein> tho I guess I could see a single "alter_children(props,
children)" which would set props, and add-incomplete/delete children in
one fell swoop, and thus complete a directory
<julianf> Hmm, interesting. (Name: "alter_dir".)
<gstein> in short, I would prefer more synchronous completion, rather
than coupling across calls,
<gstein> and am very much open to that discussion,
<gstein> I'm going to be less receptive to incomplete ops (like omitting
children),
<gstein> so just giving a warning :-)
<julianf> It's analogous to the perceived need for all a dir's children
to be known by name when it's added. Sounds to me like if the dir's
children need to be know when added, then also in one step when a dir is
modified, (and if not then neither is necessary).
<gstein> right
<julianf> "It" = send new children-list in a modify-dir call.
<gstein> which I had not considered until we discussed just now
<julianf> OK, enough to be thinking about. Thanks.
<gstein> it could delete a bunch of children in one shot. and create a
bunch of incompletes for later adds to finish.
<gstein> but: those "deletes" need to be careful, since they may need to
be a move.
<gstein> (and we'd assume a replace would continue to list the name in
an alter_dir(), to be followed later with a replace on a subnode)
<julianf> ("specify the complete children list" is dir<->file analogous
to "specify the complete text of the file", which is a nice symmetry.)
<gstein> thanks for pondering on the interface
<gstein> we've learned a lot from the first editor interface,
<julianf> np. Lunch now.
<gstein> and I think we can vastly improve it
<gstein> kk. laterz
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395468
Received on 2009-09-16 13:45:25 CEST