> > 1. Instead of writing sentinels *within* external files, Leo's file-write > logic could easily create separate **sentinel files**. Sentinel files would > contain: > > - a header with data such as sha1-hash for the corresponding public file, > and a gnx-like author/timestamp field. > > - a list of sentinel lines themselves. Each sentinel line would be > preceded by a relative offset of the sentinel within the corresponding > public file. Using relative offsets means that most offsets would not > change if a line were inserted/deleted from the public file. > > Like I've mentioned in a previous post, why not just store this sentinel data as attributes of the root node of an @file tree instead of in sentinel files.
> 2. Leo's file-read logic for public files would "shuffle" the sentinels > into the public file (using the relative offset of each sentinel). After > the sentinels have been restored, the read logic would be identical to the > present @file read logic. > > Instead of "shuffling" the sentinels from the sentinel file into the public file, just read the public file and then "shuffle" the stored sentinel data into the file data and then apply the @file read logic. And as terry has mentioned, i think each leo user would probably have their own view of the public file. However, by having the option to export the sentinel data stored in the @file tree root node in a separate sentinel file, a leo user can share his own view to others if there is a need. The exported sentinel file could even be just a regular leo file but containing only the public file's @file tree. This leo file can then be imported by other users in their own leo files. You could even add a flag attribute in the @file tree root node which will control whether the sentinel data is stored as a node attribute or saved in the public file. So if a team is composed only of leo users, you can set the flag to output sentinel data in the shared files. For mixed teams or for solo leonine user who doesnt want sentinels in the external file (like myself), you can set the flag to store sentinel data as node attribute. An added benefit of not storing sentinels in the external file is that the constraint of making sentinels as unobtrusive as possible will be removed. So more info can be added in the sentinels to make the @file directive more robust and reliable. Eric -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
