On Wed, May 14, 2008 at 06:11:17PM -0400, Richard Heck wrote:
> (ii) Bo packs everything into the LyX file using base64 encoding; I put the 
> files in a subdirectory and then wrap the whole bundle into a zip file.
>
> 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.

Base64 blobs have the distict advantage of retaining the possibility to
edit the .lyx file in a text editor - which I used to do quite often...
>
> So there's really only one thing to discuss. That said, I'll try to clear 
> up some confusions below.
>
>> Approach one: individual embedding.
>> 1) Each and every external file can be embedded individually, using an
>> embed checkbox in related inset dialogs.
>> 2) The embedded files are written directly in the '.lyx' file encoded in 
>> base64.
>> 3) If users provide a password, the original filenames of embedded
>> files are saved in .lyx file. Otherwise, the information is lost.
>> 4) Global 'embed-all' and inset-level features (undecided yet) such as
>> 'un-embed', 'update from external file' will be provided. These
>> features can make use of file link information if they are available.
>> For example, 'extract all embedded files' will be able to recover the
>> .lyx file and external files in their original directory structure.
>> This achieves full reversibility between 'embed all' and 'extract all
>> embedded files', which are called 'bundle' and 'unbundle' in the
>> second approach.
>>
>> Major benefits:
>> 1) There is no change to existing .lyx files. The .lyx format is still
>> in plain text.
>> 2) Users can work with external, potentially out of tree, files as before.
>> 3) Users can embed/un-embed individual inset, bundle/unbundle all
>> external files, without loss of information.
>>
>> The criticisms:
>> 1) These 'embed' checkboxes cluster the inset dialogs.

New feature needs new interaction. I don't see a real problem here.
I'd even go further and have tools like 'Embed all graphics' etc.
somwhere in the menus.

>> 2) The .lyx format is more difficult to work with than a zip format
>> (approach two). Base64 strings may confuses index-generators such as
>> google desktop.

Do we care?

Apart from that note that 'base64' does not necessarily need to mean
'base64'. We could as well decide to employ some custom encoding for
embedded items with a high proportion of plain characters, e.g.
something similar to what less does ("<E4>fooB<B5>ar") which might even
(a) be indexable and (b) editable by texteditors.

> 3) The code needed for this approach is much more complex than the code 
> needed for the other approach.

This might at least partially be a problem of the actual implementation,
not of the concept...

Andre'

Reply via email to