Re: please fix preference caching etc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Haha, a feature. Has SM development been taken over by MS?;)

If anyone were to ask me to outline a decent solution for toe vulnerability in the prefs/identity system I'd say stuffing them in a database would do the trick.

Sure query results can be/are cached but the great thing is that 999 out of a 1000 times if not more, a half decent chosen query for storing or reading data is faster than the per file based pref/identity system. And on a system with a lot of users that difference is more important.

I've done some experimenting with turning caching off in SM and it becomes so slow that it just isn't funny anymore, it's hilarious:) And that's with just 1 user.

The risk of data corruption when you store prefs/identities in a db is a lot smaller if not non existent since you only store the altered data, not all the cached data which would be a good practice to follow in any case;) And do an actual read of all the data wherever that's important which can be determined by checking a checksum difference between data stored in cache and data stored in the db. Do this asynchronous every x seconds (could be a pref;) ) and the user doesn't have to experience any slowdowns and when there is a  difference fill the cache with the up to date entries.

Do it like I propose and no complicated cache preference controls are needed and all functionality works the way it should under all circumstances. Wouldn't that be a great world to live in?;)

Pat




Op 6 jul 2010, om 21:52 heeft Tomas Kuliavas het volgende geschreven:

> Patrick Bos <patrick.bos <at> zjipz.com> writes:
>> So having more prefs available makes a structural design flaw allright?
>> 
>> Wow;)
> 
> It is not a design flaw, but a feature. :)
> 
> Web pages are stateless. Every time webmail pages are loaded, they need 
> to get user's preferences. In SquirrelMail some user preferences change 
> the way interface works. For example, user hits "Send" in compose.php 
> and before user's actions are processed, preferences change. It can 
> change the way redirection works, list of identities. system folders. 
> SquirrelMail needs cache in order to keep interface consistent.
> 
> You might redesign preference structure and separate cacheable and 
> uncacheable preferences, but "to cache or not to cache" depends on 
> setting and on page where these settings are loaded and even on processed 
> user action type. In file based preference system, all your preferences 
> are in one or few files and you can't refresh only individual settings. 
> Cache controls make preference system overcomplicated, are useful only in
> extreme cases and those extremes can have different control requirements.
> 
> IMHO SquirrelMail database preferences use cache too. You haven't 
> noticed performance hit, because it was less visible than in file based
> preference backend.
> 
> If you don't like dependency on SQL server, you might store prefs in 
> SQLite databases. They are files and don't need some server. SQLite was 
> not mature enough when SquirrelMail was written, but maybe now it can be 
> used more effectively than in 1999.
> 
> -- 
> Tomas
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> -----
> squirrelmail-users mailing list
> Posting guidelines: http://squirrelmail.org/postingguidelines
> List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx
> List archives: http://news.gmane.org/gmane.mail.squirrelmail.user
> List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
-----
squirrelmail-users mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx
List archives: http://news.gmane.org/gmane.mail.squirrelmail.user
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users


[Index of Archives]     [Video For Linux]     [Yosemite News]     [Yosemite Photos]     [gtk]     [KDE]     [Cyrus SASL]     [Gimp on Windows]     [Steve's Art]     [Webcams]

  Powered by Linux