[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
Fr Jan 28 2011 07:58:25 EST von IGnatius T Foobar @ Uncensored Betreff: Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff This may all be true. What I'm *not* willing to do is go to disk to check the msglist for the current room before each and every message fetch. I'm sure the tree will be quite unbalanced after the user visits one room, since it is loaded linearly. As other rooms are visited it should theoretically begin to even out. I tried a different approach at first, where we cached the msglist loaded during any CtdlForEachMessage() operation, and then checked it later. It worked *most* of the time, but there were some edge cases where it simply didn't work. For example, when saving a calendar event, we were heading over to the My Citadel Config room, which burned the cache for the calendar room, and then going back to the calendar room and requesting a specific message number we already knew. That would fail every time. There is the possibility of caching the msglist when we first arrive in a room, but that could have an effect on interactive performance as well. since we frequently go over to the config room, how'bout up to n (maybe n=5) rooms? plus... I think it would be a good thing to have the 'last wirte' timestamp of a room, which could be used to revalidate the cache
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
On 27/01/11 23:25, IGnatius T Foobar wrote: Ok. This solves the problem of I can request arbitrary msgnums and the server will give them to me whether or not they exist in a room to which I have access -- which was only a minor nuisance before, but with Citadel sites being exposed to the public Internet with anonymous guest mode enabled, that would have become quite a large problem. Imagine how lovely it would be if Google indexed it all. :) Unfortunately it takes a little more memory than I wanted it to. I'm also concerned about the binary tree: If the binary tree is not bulk-populated at the start and in a balanced fashion, but rather as messages are seen, then if messages are seen in mostly numerical order, which will happen in folders with large numbers of messages - the sorts of folders where we really want the benefit of a binary tree, then we will end up with an unbalanced binary tree, which will be as bad as a linear search but taking up a lot more memory. Further, if the tree caches seen message, it means that if a message has been seen at all in a session, it can always be seen until the session logs out, even if the message has been removed from all rooms available to the user. In other words it makes it hard to withdraw access. Maybe the user hadn't even read the message, but merely had it loaded into a room index. The admin moves the message to a restricted room, but all users who ever had it listed in their index can still see it until they log out. It seems to me that the new code is worse than the old code in terms of memory usage, not better in terms of the cases that ought to benefit, and worse in terms of security. I think the binary search of the linear list that was committed is a better solution. If a binary tree is used, it should be a balanced tree. I think there are bigger potential performance gains than can be had here, if performance is a problem. Sam
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
This may all be true. What I'm *not* willing to do is go to disk to check the msglist for the current room before each and every message fetch. I'm sure the tree will be quite unbalanced after the user visits one room, since it is loaded linearly. As other rooms are visited it should theoretically begin to even out. I tried a different approach at first, where we cached the msglist loaded during any CtdlForEachMessage() operation, and then checked it later. It worked *most* of the time, but there were some edge cases where it simply didn't work. For example, when saving a calendar event, we were heading over to the My Citadel Config room, which burned the cache for the calendar room, and then going back to the calendar room and requesting a specific message number we already knew. That would fail every time. There is the possibility of caching the msglist when we first arrive in a room, but that could have an effect on interactive performance as well.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
Ok. This solves the problem of I can request arbitrary msgnums and the server will give them to me whether or not they exist in a room to which I have access -- which was only a minor nuisance before, but with Citadel sites being exposed to the public Internet with anonymous guest mode enabled, that would have become quite a large problem. Imagine how lovely it would be if Google indexed it all. :) Unfortunately it takes a little more memory than I wanted it to.
