[Kolab-devel] Kolab XML specification

[Steffen Hansen]

On Thursday 12 May 2005 02:31, Martin Konold wrote:
> Am Mittwoch, 11. Mai 2005 11:57 schrieb Steffen Hansen:
>
> Hi Steffen,
>
> > There has never been talk about making the php script a
> > disconnected imap client (which it essentially is if it has a local
> > cache of imap ID<->SID relations). I'd rather not implement this
> > because it is going to be a) error-prone, and b) quite an effort.
> > And it doesn't solve the problem for the webclient, which is still
> > online imap and faces exactly the same trouble as the invitation
> > handling script.
>
> Actually there was a _lenghty_ discussion with the webclient
> developers about exactly this problem. It is a misunderstanding that
> maintaining a Imap ID <-> SID map means implementing a dimap client.
> It only means to have a simple _cache_ semantic on the client side.
> Of course online imap clients use in-memory or on-disk storage of
> temporary data in order to speed up operations all the time.

This cache stores message content (partial message content, the SID to 
be exact) and needs to be kept in sync with the actual messages on the 
server -- this is exactly the disconnected imap sync algorithm. Maybe 
some details like subfolder sync etc. can be left out, but all in all 
it's the same.

> Due to the simple fact that php based scripts are restarted over and
> over again using on-disk storage for caching the Imap ID <-> SID map
> is much more efficient than rebuling this structure in memory over
> and over again.

It doesn't build any structure over and over again. It uses the cached 
freebusy list to get an overview of the calendar folder. Freebusy 
creation could be faster, but that's another topic...

> > > Thus causes significant load on the server for large
> > > installations.
> >
> > Can we agree that it can at most cause a linear traversal of the
> > metadata for a folder? This is no harder for the server than a
> > sync.
>
> No, we can't aggree on that as the load for doing searches on the
> custom mail headers is much more expensive than a sync.

Custom mail headers? I am only searching on the SUBJECT -- and that one 
is in cyrus' header cache, so it is definitely faster to let the server 
traverse it's cache and return a single item compared to a sync that 
requests a list of items from the same cache. For the search to be 
slower than a sync, either scanning the cache or the string-compare 
function has to have worse than linear complexity. I doubt that is the 
case :-)

regards
-- 
Steffen Hansen          |       Klarälvdalens Datakonsult AB
Senior Software Engineer|       http://www.klaralvdalens-datakonsult.se
                        |
                        |       Platform-independent
                        |       software solutions