myself I understand the point, but ....
you probably could consider the caching as a feature that is not exactly
part of the library, the same as data source abstraction is not part of the
library. You have milions of ways to implement the cache (or even different
layers)...
read here
http://www.mobiphil.com/?p=100
(or pasted below)
You should probably play more with the wt code, to understand it. Personally
I wanted to start sthg. like you, I think I even sent you an email to work
together, but as I needed ajax, I was fascinated tha sthg. like wt was
already in place.
from blog...
in an elegant design a web applications presentation layer (or equivalent
ones) should not make tricks about caching. I see often bad code like
following everywhere, especiall written by php kids:
<code>HTML Page::getHtml() {
if(cached)
data = getFramCache()
else
data = getDataFromDatabase()
}
</code>
one should create polymorfic database, or use templates to hide caching in
the data source pattern.
<code>Widget::onEvent(IdClass id)
{
Datasource *datasoure = Datasource::singleton();
datasource->getData();
}</code>
<code>Datasource::getData(Key &key)
{
//do some sql
}</code>
then you could have
class DatasourceWithCache: public Datasource
********
<code>Data *DatasourceWithCache::getData(Key &key)
{
Data *data = getFromCache();
if(!data)
Datasource::getData(key);
return data;
}</code>
The cache could be shared between threads or processes (!!security
issues!!), or just one process.
Your framework should initialize the singleton with the correct datasource.
You could create a config file, and specify the activation of the cache. You
can implement a datasource based on sthg. like memcache (so much venerated
by php kids).
Let's take a simple example with a web application that would have different
views (pages) of the same table data. If you change one cell in the table,
all the other cached views should be invalidated in the "classical"
approach, whereas with ajax approach, you should invalidate the cache only
for that particular cell. If this level of cache is not enough, you could
always find a compromise and with a bit more complex cache, one could cache
the whole rendered widget data, but here the widget code itself would
probably need to help. (and thus a bit in contradiction with the first
statement). Anyway there should be a balance between the necessity of the
cache.
Another example, a wiki engine, or blog engine. With wt, one would need to
cache the pages data, not the decoration around. The decoration would not
change during going from one page to another one. So one could specialize
the datasource by providing rendered (converted from wiki syntax to html).
And thus one would just feed the wiki widget with cached data.
On Fri, Feb 20, 2009 at 7:24 PM, Artyom <[email protected]> wrote:
>
> > We do not cache "content", as there is not really
> > any "content" concept in Wt.
>
> Without proper caching Wt would not be able to scale up well.
> There are many central resources like data bases that are shared
> between processes.
>
> Otherwise every hit would cause DB access and the application
> would die fast. You just have to relay on some shared resource,
> you need a way to update cache.
>
> Scaling and creating balanced system is **very** compilcated task,
> you just can't tell I'll double the number of computers I use
> and the system would increase performance in two times.
>
> >
> > > and more then 1 server and share common data like
> > session information?
> >
> > You can deploy a Wt application behind a standard load
> > balancing
> > reverse proxy that knows how to deal with session affinity
> > by matching
> > a regular expression on the URL (when using the built-in
> > httpd using
> > --session-id-prefix). Wt itself does not require shared
> > common data
> > like session information.
>
> Session is only **one** kind of object that may be shared
> between systems -- there are many others like cache and DB.
>
> > For Wt the answer is quite simple: scalability is linear
> > except when
> > the load balancer would become the bottle-neck (but then
> > there are
> > other solutions), or when the application logic itself
> > contends for a
> > common resource.
>
> As I told in reallity you just would not be able to hold "linear"
> effect unless your application is really slow.
>
> Another point that scalability is not just how linear can you be
> but also how do you perform well. The key is "cache", "cache" and
> more "cache".
>
> Its easy to write web application that can hold 10 hits per second
> even in PHP. 100 can be done using C++ or using basic caching with PHP
> 1,000 can be achieven using lot of caching and C++ (and this is
> if you have 100% cache hit ratio)/
>
> -------------------------------
>
> But, if you primary marked is embedded system then really you
> do not need caching or worry about scaling.
>
> Best Regards,
> Artyom
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> witty-interest mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
