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: [EMAIL PROTECTED] This is the first file "foo". [EMAIL PROTECTED] the second one, "bar" [EMAIL PROTECTED] 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 "[EMAIL PROTECTED]" 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 "[EMAIL PROTECTED]" 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 _______________________________________________ gnu-system-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-system-discuss
