I want quickly to summarize where I think this discussion is now.
There are two proposals on the table, one due to Bo and one due (more or less) to me. The details of these have been described elsewhere.
Many of the apparent differences between the approaches are just implementation details. Bo base64 encodes embedded files and writes them at the end of the LyX file, whereas I put them in a subdirectory and (optionally) zip (or whatever) the whole thing. This does matter, because my approach is compatible with the Mac-magic that JMarc has mentioned, whereas Bo's is not. But either of us could proceed either way. Similarly, Bo keeps a map between the original files and their embedded counterparts in an encrypted section of the LyX file, whereas I'm inclined to use a session file. But we could each do either. Etc, etc.
The only real difference is over the question whether one should be able to embed individual files on an inset-specific basis versus having an on-off switch that either embeds everything or embeds nothing. Again: Everything else is essentially identical. (Bo may disagree with this, but I've argued this elsewhere and am tired of repeating myself.) The issue is whether it's worth the code complexity and UI clutter to allow individual embedding. I don't see it, because the only use cases I can imagine that make use of individual embedding are so unlikely actually to occur.
Here's one way to look at this. Suppose Bo's approach offered an "embed all files by default" button. I think it clearly should. Then (i) Bo's approach is indistinguishable from mine so long as that button is checked. And (ii) 99.9% of users will use that button and never touch the inset-specific stuff. This is because the format is intended to be used for such purposes as Bo describes here:
But my goal is a bit more. In short, it allows you to send a .lyx file to your advisor, he can simply open, view, edit and print it. The instituion-specific class and layout files, and your figures are embedded.
And, of course, this means that you will want to send your advisor, co-author, editor, or whatever everything associated with the LyX file, since (a) you want them to be able to compile it, and (b) in cases of co-authors, either of you could, in principle, change any associated file. So what you'll actually do is embed everything, not selectively embed here and there.
Now sure, if it were possible to allow individual embedding without significant cost, then why not? But there is significant cost, both in terms of code complexity---this is just obvious, because the one approach has to manage inset-specific stuff but the other does not---and in terms of UI clutter. So we have to ask what the benefit would be. And that's yet to be said, except for the suggestion that some company might want to embed a single graphic into a letter template, which I for one do not find impressive.
So the question that seems to me to need answering is this one: Do people think a sufficient case has been made for Bo's particular proposal, i.e., for inset-specific embedding? Please note that the question is not: Bo's or mine? I do NOT say that a sufficient case has yet been made for proceeding with mine. People can express a view on that if they wish, but it might well be better to wait until more of the implementation is in place, and then you can actually use it, see how it works, and then compare the benefits to the code, UI changes, etc, that are involved. (If you want to see more or less how it works, checkout my private branch and compile it. It does more or less work, with limited functionality.) It will be some time until I can work on that again, though. Or on anything besides bug-fixing, which is probably what we ought all to be doing. (Uwe, that was for you.)
We don't have to do anything now. (I.e., we can punt.) Enrico's python script is pre-alpha, but it wouldn't take much to polish it, and it could be made to do a lot of what some of us would want, if not everything. Indeed, part of the reason I'm not convinced that my approach should actually be added to the code base is because I'm not convinced that Enrico's approach could not be made to work. And if it could, then it might be more flexible. (Though the Mac-magic is enticing, especially if it turns up in Linux....)
Richard
