On Thu, Aug 27, 2009 at 6:34 PM, Ville M. Vainio <[email protected]> wrote:
> > On Fri, Aug 28, 2009 at 2:13 AM, Edward K. Ream<[email protected]> > wrote: > > > One possibility would be to disable caching for @file nodes. > > Disabling the caching for @file sounds right if there are problems > (it's not like we need to speed up deprecated features). We should do > it in 46-maint as well. Imo, there is little doubt that caching is causing @file nodes to fail. The problems I had earlier today were in the trunk, so the one-node branch can not be blamed. My present opinion is that caching should be disabled for all nodes except @thin nodes. The read logic for the various kinds of @<file> nodes is subtly different, and I am far from convinced that caching has been thoroughly tested. Presumably uA's survive in @thin trees because of the the so-called "hidden machinery" in @thin files, that is, the descendentTnodeUnknownAttribute in the <v> element in the @thin node. The hidden machinery exists only for @thin trees. Independent of caching, I have been considering what to do about @file nodes. It seems that the simplest, safest and best approach is simply to leave them alone. That is, to make no changes at all to the Leo concerning @file nodes. As I have learned today, there are considerable difficulties in converting @file nodes to @thin nodes. No strategy is either intuitive or simple. The risks of alienating users is real, as is the risk of introducing time-bombs in the "helpful" conversion code. So I think we should just advise people not to use them in cooperative environments and leave it at that. > > > I do hope I am wrong, but it looks like there could be big problems > > with caching in 4.6.2. > > Luckily, you seem to be wrong ;-) The problems happen in the trunk, so I don't see how we can pretend there are no problems. It may be that the problems are confined to @file nodes, and that we can solve those problems simply by never caching @file nodes, but I'm having troubles with the trunk, and I know of no changes that would have broken the trunk. In other words, I think the problems existed in Leo 4.6.2. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
