On Wed, May 14, 2008 at 6:01 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
>> Please, there is no 'free write back to tree' stuff ...
>
> then i haven't been able to get reasonable image of proposals from
> your summary.
Well, you have not told me where you got this 'free write back to
tree' feeling. I assume that you meant the unbundle process and I have
answered your question:
<Quote>
> i was trying to retrieve your solution by adding the constraint of only
> the current dir+subdirs write acces or something in this way,
> but you seem do not like it too.
I am confused. I have specifically said that the 'unbundle' action
would extract to a subdirectory under the document directory, just
like what will happen when you export to HTML, latex, or whatever. Why
is there any security hole here??
</Quote>
And I actually have answered that from my first reply
<Quote>
Unbundling will be an
export feature that writes a .lyx file and its extracted external
files to a new subdirectory under the document directory. The current
.lyx file is not changed.
</Quote>
If this is still not clear enough. I do not know what else I can say.
> and frankly from both answers i feel you both haven't been able to
> understand each other yet.
> maybe it would be better idea to setup wiki page where each of you could
> write how your proposal work in more algorithmic way, unify what the
> words like bundling/reversibility means and only after that make some
> comparison of pros x cons. i'm myself lost from your posts now, sorry.
The purpose of this thread is to summarize the debate. I have posted
my patch a few times. Richard has a private branch. Code wise, there
are solid code pieces.
Let me show you what is so confusing here.
=============== The non-reversible issue ==================
In the first email of the "Alternative to individual embedding?"
thread, I stated
<Quote>
4. The switching between bundle and unbundled mode is non-reversible.
For example, when ../figures/figure.png is copied to
filename.lyxdir/figures/figure.png during bundling, it is not copied
back during unbundling. That is to say, if you work in unbundled mode
locally, send your document in bundled mode to your co-author, you can
not get your external files back when the document is sent back.
</Quote>
Richard replied
<Quote>
This discussion would also involve the words "session-based alternative".
</Quote>
And later I said,
<Quote>
You mentioned that the non-reversible problem can be solved by a
session approach, but you have not said how you would like to use it.
Will you copy your files to their original, potentially out of tree,
locations? If true, you are facing the same security problems you
mentioned.
</Quote>
And Richard replied
<Quote>
As I said elsewhere, I don't attempt reversibility in that sense,
because of the security problems.
</Quote>
And now in this thread, I said
<Quote>
1) Not friendly to existing files. A .lyx file will be permanently
changed if it is turned to the bundled mode. Switching back to
unbundled mode will not recover the original .lyx file. (Richard said
that he does not offer reversibility in this sense.)
</Quote>
And he replied
<Quote>
OK, now I understand what some of this reversibility talk has been
about. I thought we were talking about restoring the bundled files,
not restoring the LyX file. So I haven't said I don't offer
reversibility in that sense, since I wasn't ever talking about that.
And I don't say that. I could do reversibility in this sense if I
wanted to do so, and in much the same way Bo does.
</Quote>
What a surprise! After so many communications, he did not even
understand the problem??
However, I have stated long ago that his approach can not unbundle in my way.
<Quote>
The biggest different between our approaches here is that with
'unbundling', your users work on a different mode, but on the same
(changed) document; and my users continue to edit the same document
because there is no unbundled mode.
<Quote>
Currently, Richard's unbundling does not copy/move files within
filename.lyxdir. After 'unbundle', users continue to work on the
existing document. IF he would like to unbundle in my way, namely,
extracting a document with its external files to a subdirectory, will
he open that extracted file for continued editing?? This is not a
simple 'I could do reversibility in that sense', even if he could, it
means a major change to his proposal. Even Richard understood this:
<Quote>
If I just copied filename.lyxdir/ to emptydir/, then I'd have EXACTLY
what you get from Bo's "unembed all files". But that does seem rather
pointless.
</Quote>
except that he was wrong that copying filename.lyxdir to emptydir/
does not solve the reversibility problem. The original external file
structure needs to be restored here.
Anyway, it is good to see that 'I could do reversibility in that
sense'. At least he admits that reversibility is important.
============== About the session idea ===================
<Quote>
>> I have stated
> > reasons why I dislike the session idea.
> Would you mind stating them again? I can't for the life of me see the
> problem.
The session idea assumes that the document will be edited by one user
on one machine. This limits the reversibility of a document to only
one user on one machine. For example, if someone modifies our user's
guide in bundled mode and sends it to us, we can not apply the changes
to our tree because only he has the session file.
</Quote>
Now, when facing the reversibility problem, Richard states
<Quote>
But doing this just involves using the mapping, so we can do it as
long as we have the mappoing, and I have it, too. The only difference
here is that I have been thinking it should be kept not in the LyX
file but in the session file, but that isn't a real difference either,
since I can do it either way, too. So there's no real difference here.
</Quote>
I interpret this as Richard did not really care about these file links
and thought that it would be enough to keep them locally. Now, the
session idea is not good enough to solve the reversibility problem.
======================== The zip idea =======================
It appeared that Richard has not decided on the zip idea.
<Quote>
But that's just a confusion, and there's no real difference here.
First: I OPTIONALLY wrap the bundle into a single file. There is a
real difference between a "bundle"---that's just a LyX file with an
associated directory---and what we might call a "wrapped bundle",
which is the single file. Second: How we wrap the bundle is an
implementation detail. If we want to wrap it by base64 encoding
everything, then we can do that. Or we can use tar. Or whatever.
</Quote>
<Quote>
2) The plain text file is more svn friendly, easier to work with for
tasks other than extracting external files. I do not really care about
index-generation applications. I also pointed out that this format is
more natural for individual embedding. (No zip/unzip states).
This is just confused, because approach (2) does not use a zip format.
I've explained this above.
</Quote>
However, in the previous thread, Richard said:
<Quote>
The thought was just that, if you turn on compression AS WELL AS
bundling, then you should get a zip of the whole thing, and then it
should be possible to open this "*.lyz" file in LyX and work with it.
But this isn't implemented, and it isn't a file format change in any
interesting sense. We already have compressed files. There's no reason
we can't add the "bundle directory" to the zip.
</Quote>
He obviously meant this zip idea because he said:
<Quote>
In my approach, there is absolutely no file format change, except for
a buffer parameter flag.
</Quote>
I mean, he did not like the base64 idea because it involves file format change.
Then, a lot of people was talking about the advantage of zip over base64,
<Quote>
I like Richard's solution better. Having a zip based solution means that you
can 'unbundle' from the command line even without LyX, the base64 solution
is more complex.
</Quote>
Richard did not deny the zip idea at that time, until I said that zip
is not svn friendly.
I guess you now know that it is not me who could not under Richard's
proposal, it is Richard who does not understand his own proposal.
Cheers,
Bo
