Hi all,
I implemented the caching because I needed it for the handbook app to be
usable, as I have explained before.
You are right: No decision was made and it was obvious that no decision
was going to be made for now as I seem to be the only one who needs
caching short-term.
So I had some option
Cheers Sven,
I am afraid you were faster than me.
So far I added the following:
- client (browser caching)
- server resource caching (css/javascript) on disk
- system caching of configuration (global/user settings plus
registrations) on disk, i.e.
While I understand the overall ca
Dear fellow developers
As you all may know we have been discussing the topic of caching in
chamilo a few weeks ago on the mailing list. As far as i know there was
not a real decision about how it would be implemented and who would
implement it. Though there was no real decision i have noticed
Hi Laurent,
as long as the caching "app" is only used by other optional applications
it is not such a problem, since you can make it a prerequisite for the
application so you can always be sure the classes exist.
If core-applications want to use the caching it will have to become a
core applicati
> Cheers Nathatlie,
> Thanks for the work.
>
> While I understand the reasons to put it in a separate package I think
> it would be better if we moved it to the core. If not now then at
> least in the future.
+1
___
Dev mailing list
Dev@lists.chamilo.
Cheers Nathatlie,
Thanks for the work.
While I understand the reasons to put it in a separate package I think
it would be better if we moved it to the core. If not now then at least
in the future.
There are several parts - global comes to my mind - that would very much
benefit from it.
If we d
Hi all,
I have made an extra, optional, Chamilo 2 application to handel the
caching for the handbook and portfolio for now.
https://bitbucket.org/NathalieB/chamilo-app-cache-dev/
it is set-up so you can use different caching-mechanisms (applications
can specify which caching implementation to use
cific
>>> than "Re: Contents of Dev digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>1. Re: caching data in php (Nathalie Blocry)
>>>2. Re: caching data in php (Sven Vanpoucke)
>>>
>>>
>>> ---
cry)
2. Re: caching data in php (Sven Vanpoucke)
--
Message: 1
Date: Wed, 27 Apr 2011 15:13:13 +0200
From: Nathalie Blocry
Subject: Re: [chamilo-dev] caching data in php
To: dev@lists.chamilo.org
Message-ID:<4db81669.5080...@vub.ac.be>
Content-Type: text/plain; charset="
7;s Topics:
1. Re: caching data in php (Nathalie Blocry)
2. Re: caching data in php (Sven Vanpoucke)
--
Message: 1
Date: Wed, 27 Apr 2011 15:13:13 +0200
From: Nathalie Blocry
Subject: Re: [chamilo-dev] caching data in ph
Right and I think you can trigger the cache cleanup by putting a call in
a desctructor.
So that it is called after the code has returned all data to the end user.
Le 27.04.2011 15:13, Sven Vanpoucke a écrit :
We could have an extra administration option to deleted temporary
files / caching data
I think both options are valid.
The db cache should certainly have timestamps column to decide when to
purge an item.
So a purge could be a DELETE .. WHERE enddate<
We could put an abstract method clear_old_data in the parent Cache class
and leave implementation details to the child class
Re: caching data in php (Nathalie Blocry)
> 2. Re: caching data in php (Sven Vanpoucke)
>
>
> --
>
> Message: 1
> Date: Wed, 27 Apr 2011 15:13:13 +0200
> From: Nathalie Blocry
> Subject: Re: [chamilo-dev] caching data in php
> To: dev@lists.cham
We could have an extra administration option to deleted temporary files
/ caching data.
Sven
Op 27/04/11 15:13, Nathalie Blocry schreef:
Caching per run does not solve my problem at all since the menu is
only build once per run anyway. Keep in mind that the
handbook-content-table is also us
Caching per run does not solve my problem at all since the menu is only
build once per run anyway. Keep in mind that the handbook-content-table
is also user-specific and not really static. I dont understand
"denormalizing your database layer and storing some of these values
locally in your applicat
I would personally go for a file cache because it's much more easy to purge.
If the Caching engine is responsible to get any cached data, we can have
it check how old it is and either return the old data or recompute and
return the data.
What do you think o that idea ?
Systho
Le 27/04/2011
Triggering these actions on an event like a user logout isn't a very
good idea either. Because not many users actually use the logout
button. In fact, triggering this with any event, like for example the
login could make this event very slow...
I am very much in favor of introducing caching i
I agree but the interface should not be that difficult to design. It's
mostly a question of looking at existing implementations - memcache, apc
- and extracting the core functionalities.
By doing that we leverage the work already done by those teams.
Then we can add a DB implementation which sh
I would rather go for serialize/unserialize as it is meant to store objects.
As for file serialization this is certainly doable but I would make that
just another implementation. In this case we have to ensure we use a
shared cache if we use several application servers.
I didn't realize that
I think we can all agree this is not a small thing and to find the
optimal/best solution we need a lot of research but I also really don't
think we can release the handbook app before we have caching. I am
afraid we are not talking about sacrificing *some* speed but for the
help/documentation we wi
I hope that by now it's clear that this is a big subject, not to be
taken lightly at all. Implementing this before the freeze / merge /
whatever-you-want-to-call-it at the end of May does not seem realistic
to me. If and when this is implemented we need detailed "research" on
how this will happ
If you go for cron, don't forget that chamilo should be usable on
mutalised hosting where cron is not available. What about file
serialization and var_export /__set_state() functions ?
the mtime can be checked directly in php code
Systho
Le 27/04/2011 12:46, Laurent Opprecht a écrit :
I belie
I believe a DB implementation would be a good first move - at least we
are sure it will be available :-).
I would just ensure the implementation is compatible in term of
interface with APC - which should be more or less a standard by now.
I.e. have functions such as add($key, $value, $time_to_l
I have made a wiki page on this subject:
http://support.chamilo.org/projects/chamilo-20/wiki/Caching
I know striclty speaking this is a new feature but I am convinced we
really need some kind or caching before we can release the handbook app.
I could implement it for now just for the handbook, bu
That's the Chamilo 2.0 spirit *thumbs up* 8-) :-)
Hans
On 26/04/2011 12:42, Laurent Opprecht wrote:
We may abstract the caching mecanism.
Something like:
class Cache
class ApcCache extends Cache
class MemCache extends Cache
class DatabaseCache extends Cache
class Sessi
Op 04/26/2011 12:26 PM, Sven Vanpoucke schreef:
> I don't think it's a good idea to use caching in the session variable.
this is exactly why I am looking for the best alternative.
caching on the session was done for now to test how much it would speed
things up.
Op 04/26/2011 12:42 PM, Laurent Op
We may abstract the caching mecanism.
Something like:
class Cache
class ApcCache extends Cache
class MemCache extends Cache
class DatabaseCache extends Cache
class SessionCache extends Cache
class EmptyCache extends Cache //Empty pattern
...
With a factory method insi
Hi
I don't think it's a good idea to use caching in the session variable.
We should try to keep the session variable as clean as possible (and
it's already messed up with quickform stuff...). I think in your case,
the best solution could be to have a DB table in the content object of
the han
Hi all,
For the handbook application I realy realy realy need caching because
otherwise the application becomes very slow.
without caching a lot of processing and data-retrieval is needed: for
every item in the handbook all the alternative versions and their
meta-data need to be retrieved so that
29 matches
Mail list logo
