Can 'sidecar' files carry outline structure?

[Largo84]

Advance apology if this has already been considered and discarded as impractical, stupid or whatever (since I'm not a programmer)....,but I work with raw image files in photography that have 'sidecar' files (XMP) that carry the metadata and editing instructions (they're nothing more than glorified XML files with a specific purpose). The convention is that the file name is the same between the sidecar file and the raw image file. Any image editor then knows to read the instructions in the XMP file for whatever purpose. The raw image file is never actually touched or written to, just the XMP file. Different image editors can ignore any specific XMP commands it doesn't understand. It's a widely used convention in that arena and well documented.

All of the discussion recently about @shadow files and sharing outlines and the structure made me wonder if a similar strategy might work for Leo created external files. For example a Leo user opening  SomeFile.py would read the outline structure from SomeFile.xmp (or whatever file extension makes sense) The non-Leo user opening SomeFile.py would simply see the plain .py file with no sentinels. Other Leo users would need both files to share the outline structure. Just a thought......

Rob................

[gatesphere]

As far as I know, this is what @shadow currently does. There are a
number of reasons why this is untenable, but that's really Edward's
current line of thought.

-->Jake

[Edward K. Ream]

On Thu, Dec 12, 2013 at 8:18 PM, Largo84 <Lar...@gmail.com> wrote:

Advance apology if this has already been considered and discarded as impractical, stupid or whatever (since I'm not a programmer)

​It's not a stupid idea, but it won't work.  The problem is keeping the two sets of files in synch.

The best approximation I have ever come up with is to commit (transmit) files with sentinels, hand then have bzr/bit/etc automatically strip the sentinels for non-Leo users.

But this really isn't satisfactory: non-Leo users really can't be expected to do *anything* to support Leo, and this scheme requires bzr hooks for all non-Leo users.

Things would be different if Apple's old file scheme (all files have a resource fork) were industry standard.  Then the "sentinels" could be part of the resource fork.  But even so, non-Leo users aren't going to properly update the sentinels.

In short, making @auto work well is the only hope there is in practice.  This takes *all* burden off of non-Leo users, requires no infrastructure changes at all for Leo users and non-Leo users alike, and completely eliminates the need for sentinels.

Edward

[Matt Wilkie]

On Thu, Dec 12, 2013 at 6:18 PM, Largo84 <Lar...@gmail.com> wrote:

The convention is that the file name is the same between the sidecar file and the raw image file.

A big difference between images-with-side-car files and text files, like program code for example, is that images and .xmp mostly have a one-to-one relationship while arbitrary text files often won't.  For a metaphor, think what it would be like managing the files if every frame in video had it's own .xmp side car, e.g. a single .leo file with multiple @file nodes.

In the GIS world, which has many data formats utilizing multiple files to represent a single data-set (e.g. shapefile), we often struggle re-piecing data together because somewhere along the line someone dropped a side-car that didn't immediately make the data-set unusable. For example a .shp file without an accompanying coordinate system description (.prj) will work just fine for years in it's originating office, but hand it off to a colleague and they start complaining about stuff being in the wrong country and hemisphere.

Anyway, side-cars do work. The aforementioned shapefile for example is still the defacto interchange format for spatial data decades after it's inception in spite of it's many limitations, the side-car nature being one of them. It's just that there are side effects to consider.

-matt