Bo Peng wrote:
- i don't like the 'extract all embed' feature in concept1. if some chaotic
co-author on the other side embed files from different paths on filesystem
i will be _very_ annoyed by lyx disseminate these file on hundred and one
locations on my filesystem. we shouldn't allow this to happen. i dont see this
listed in cons of concept 1, but i consider this far worse deficiency than
other points written.
not to kill the concept1 completely - it could may be done that we allow
only embed/unembed files on the same directory level or in subdirs.
This has been debated. Using the second approach, because lyx has to
work on the unbundled .lyx file, it is difficult to restore relative
locations of extracted files. This is why Richard chose not to
unbundle files to their original locations. 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.
There's no difference between the approaches on this point. On my
treatment, the files are already "unbundled" in filename.lyxdir/, and
you can do with them as you like.
* does this bundling movement means my coauthor can't work reasonably with
the bundled files (its hard if they are renamed all structure lost etc.)?
Yes. The original structure of external files are lost. It is of
course possible to allow users to specify locations within this
filename.lyxdir structure, but this means more troubles for users.
If I understand the question, the answer here should be "No". The idea
is that the bundled files travel with the LyX file, and hitting "Edit"
will open the bundled file for editing. I don't know what "working with
the bundled files" could otherwise mean. And then, of course, if your
co-author sends the bundle back to you, you'll get the files in their
changed forms.
* if he changes some picture would it be easy to get this change back to
_my_ structure? if this is not somehow doable this format is not much useful
for cooperation.
No. You are forced to use a prespecified strcuture. Once you turn to
bundled mode, you can not get your structure back. This is the
reversibility problem I was talking about.
Here again, there is no difference between the two approaches. In both
cases, you get the (bundled or embedded) file back, but LyX will not
attempt to write it back to its original location. In Bo's version, it
gets extracted to some newly created subdirectory; in my version, it
just lives somewhere in filename.lyxdir/. If you want to copy it back to
the original location, you can do that. But again: LyX will not do that
for you, and it would be a very bad idea to allow it to do so.
- if i understand it correctly in both cases the filename is discarded. why?
isn't only filepath the problem?
In the first case, an embedded file is either anonymous (file links
are not saved), or with known original source, which can be relative
or absolute. I chose to password-protect both filename and filepath
because filenames alone are not enough to recover the original
external file structure.
Actually, in my approach, the filename is kept, unless it needs to be
changed to avoid conflicts. (You bundle three things named image.jpg.)
But path information is discarded for security reasons, though it can be
kept in the session file (or in some other file in the user directory)
and used for whatever purposes you wish.
now from completely different angle, imagine such kind of workflow:
1. i have all my files for typesetting some book in one directory with
possible subdir structure for chapter/pictures/repository info like
.svn or .git.
2. now i want to send it to my coauthor for revisions, new chapter, whatsover.
so i pack this whole directory into one archive and send it to my coauthor.
3. he unpacks it edit whatsover he likes. then he packs it again and send me.
4. i unpack it and start to use it normaly. in this point i can easily forget
i ever used some packing. and first thing i would like to see is usually
what happened, so some "git diff" or even "git log" should be possible.
This will be my way of doing things as well.
Same for me, I think.
now imagine we require that all bundled/embedded files are in the same
directory
or in subdirs.
the BIG question for before all: can be such constraint demanded on user at
all?
I certainly disagree, but Richard and JMarc said yes. They were
talking about not allowing any out of tree file. I strongly object any
unnecessary restriction on how users use external files.
This confuses a couple separate issues. In my version, the bundled files
themselves live inside a special directory, much the way it works in
OOo; in Bo's version, they are base64 encoded within the LyX file
itself. In either case, the bundled or embedded files are different from
whatever external files you started with. Links of a sort can be
maintained between the bundled/embedded file and the external file, but
the files are different.
My sense, Pavel, is that what you want is precisely what is provided by
Enrico's python script. You don't want to bundle files the OOo way, and
you don't really want to embed them either. You want to use your good
old external files but have it be easier to exchange a package
containing them with your co-authors. That, again, is precisely what
Enrico's script does, though at this point its just proof of concept and
needs some work.
My design goals are somewhat different, though bundles, in my sense, can
be used to simplify collaboration.
if yes the implications would be clear:
- we can use this directory as filename.dir in concept2 (or add some
cherry-picking as in concept1)
- the whole pack/unpack process seems to be more clear (at leat to me:)
In Richard's approach, you can not keep your original directory structure.
Of course you can. But the bundled files---which might as well be
visible only to LyX---are distinct from the external files. There is no
difference here between the approaches.
In my approach, you do 'embed all files' and send a single .lyx file
to your co-author. After he finishes edition, you 'extract all
embedded files', examine the files and copy them back to your
directory structure.
You can do exactly the same thing with my approach. Viz: You work as
normal; you hit "Save As..."; you turn on bundling and compression; you
save again, getting filename.lyz. You send it to your co-author. She
works on it, sends it back to you, and you open it, turn off
compression, and save, getting back filename.lyx and filename.lyxdir/,
which of course contains all the bundled files. Then you "examine the
files and copy them back to your directory structure".
If we like, of course, we can simplify the first part by allowing "Save
As Bundle...".
imagine for example we rename the bundled file extension to some,
so from that moment we know only two states:
1) projet_dir.lyz 2) project_dir/...content_of_lyz
- we can forget about the path/filename issues
- we can hold the dir structure
- in case we rename the bundled extension some another we can even
My approach continue to use plain text for embedded files and has no
trouble with external files, directory etc.
but maybe such kind of solution was already discussed, don't know;
just sharing what came up in my mind while reading the previous mail,
because in both solutions i have seen nigthmares mainly in the phase
of packing/unpacking. concept2 seems to 'solve' that by avoiding moving
the files back, which in fact means leting do the hard job to the user.
I hope that you feel comfortable with my pack/unpack solution. From
the very begining, my design was around reversibility so that I could
recover my local external file structure. My previous implementation
was convenient but may be unsafe. The current approach should work
well.
As I said, to the extent your approach has reversibility, mine does too.
There's no difference here.
rh
