Re: squid rewrite

    As your thoughts are quite similar to those I have thought of for
 quite some time, I would like you to take a look at these ideas and
 comment aggressively. As it appeares to be too big to include with a
 mail, here is a URL: http://cache.online.ee/cache/Devel/design.txt

> * Backend handlers for things that are not well tested/integrated. (like
> ftpget in current release)
> * A supervisor, that checks that everything is OK, and restarts things
> that crash.
>
> Another issue is very large objects, as always. But that is also the
> case with the current design...

    I think that squid sooner or later will need to have best of VM and
 NOVM versions mixed. NOVM has no problem with large objects, and if it
 uses VM style for objects near average size (10-20K) it can also conserve
 FD's and keep most hot objects in VM still being able to manage memory
 usage.

> Shared memory and semaphores are best let alone if we are thinking of
> being portable... and if using a central manager then it can be avoided
> without to much performance degration.

    Semaphores can be implemented in software in worst case, but is shared
 memory really a porting problem?

-------------------------------------------------------------------
 Andres Kroonmaa Telefon: 6308 909
 Network administrator
 E-mail: andre@ml.ee Phone: (+372) 6308 909
 Organization: MicroLink Online
 EE0001, Estonia, Tallinn, Sakala 19 Fax: (+372) 6308 901
-------------------------------------------------------------------
Received on Tue Jul 29 2003 - 13:15:41 MDT