Kitten

[Soeren D. Schulze]

Hello everybody...

Please excuse that I duplicate discussion from IRC here extensively,
but IRC is not the right medium for this.  Long paragraphs flood your
brain and your window and you do have the time to read it because you
have to answer quickly.  Moreover, IRC clients do not have a
thread-based archive...


Let me give a status report for those who have not read the discussion
on IRC but the initial messages on this list how kitten should work:

Trivial read-only conkittenation has been working for months now, but
that is certainly not what is interesting about kitten.  Write support
works, too, but it is very limited and you run into a couple of
problems that I am going to explain here...

First, you have to decide how to indicate which file belongs where.
Using line numbers is transparent to the user but pretty restricted to
use.  The question is whether it should be as transparent as possible
to the user at all.  Starting the write support implementation, I
thought that it should not.  Instead, the user should see where the
lines come from and be able to write data to a certain file, not
restricted to line numbers or anything.

Therefore, I thought that kitten would use "delimiters" to indicate
the beginning of a new file:

address@hidden
This is the first file "foo".
address@hidden
the second one, "bar"
address@hidden
last but not least...
EOF

That is how it would look after starting kitten like this:

$ settrans my-translated-file /path/to/kitten foo bar baz

Obviously, there is the delimiter "address@hidden" that shows where a new
file starts and how the file is named.  The term "delimiter" is a bit
confusing, however, because it does not indicate the end of a file but
its beginning.  Maybe "header" is a better word, but I will go on
calling it "delimiter" for now...

The user is now able to edit the content between the delimiters and
kitten will magically write it to the right file.  Sounds easy, right?

Unfortunately, it is actually full of questions.  What will happen if
someone just removes a delimiter from the file content?  This case is
not respected anywhere in my statements above and it would result in
highly implementation-specific unintuitive confusion.  Kitten would
see the next delimiter but it might notice that it is the wrong one.
Remaining on the strict definition above how it should work, you
cannot solve this.

OK, you might think, the user is not supposed to do this, so it is
his/her own fault if the result is unintuitive.  Unfortunately, this
case occurs even if the delimiter rules are not intentionally
violated:

Consider a tool written in ANSI C that manipulates a file in a way
that includes cutting some bytes at the end.  Unless these bytes
contain a delimiter, everything seems all right.  But the usual way
how to do this in ANSI C is to read the content of the file and then
truncate it completely.  Obviously, we removed all the delimiters that
way and kitten will get *really* confused.  So we need another
approach.  I thought up two of them:

1. One might define that all the tailing empty files in the
   conkittenation are not listed.  That way, kitten will truncate them
   all on the truncation of the conkittenation.  Because the files are
   empty then, the conkittenation contains no delimiters and is
   therefore completely empty, too.

2. A much more enhanced approach is to make the delimiters
   "sensitive": by changing the delimiter content, you can choose a
   file to join the conkittenation.  You can remove delimiters and
   create new however you like.  Just include a line "address@hidden" in the
   file and all the data you go on writing will go to file quux.
   Obviously, this is a security issue: by making one file writable to
   somebody, you make *every* file that you can control writable.
   Kitten might have an option that file that are not a member in the
   list of conkittenated files from start cannot join this way.  To do
   it the really right way, kitten should check the permission of the
   opener to write to the respective file.


I think that this is quite a long chain of thoughts and I am sure that
you have a lot of comments -- and probably also questions where I did
not explain well enough.


Sören