Difference between revisions of "User talk:Capmo"
From FollowTheScore
(→DPL Cache - ideas & question) |
|||
| Line 8: | Line 8: | ||
== DPL Cache - ideas & question == | == DPL Cache - ideas & question == | ||
| − | Definitions: | + | * Definitions: |
| − | * A wiki page which contains one or more invocations of DPL is called a ''DPL-page'' in the following text. | + | ** A wiki page which contains one or more invocations of DPL is called a ''DPL-page'' in the following text. |
| − | * A page containing pre-fabricated DPL results is called a ''cache page''. | + | ** A page containing pre-fabricated DPL results is called a ''cache page''. |
| − | * A page which is part of the DPL result (because its name or content appear within the DPL result) is called ''data page''. | + | ** A page which is part of the DPL result (because its name or content appear within the DPL result) is called ''data page''. |
| + | * Cache Levels: | ||
| + | ** closest to the user there is the browser's cache. It depends on expiration hints given in the http header (which in turn is generated by the MW core system on the server side) | ||
| + | ** next comes the ''MW parser cache''. By default this feature is ENabled on newer MW installations. If not explicitly disabled within the php code of the DPL extension the parser cache uses cached content to retrieve a page - which means that the DPL extension is not invoked at all. | ||
| + | ** third comes the cache level I think about. If the DPL extension is invoked it uses its own strategy to decide whether it should generate output by querying the database or whether it can use older results instead. | ||
| + | |||
Basically my idea is based on the fact that DPL internally produces ''regular wikitext'' in a first step. | Basically my idea is based on the fact that DPL internally produces ''regular wikitext'' in a first step. | ||
Revision as of 14:28, 20 May 2009
Hello Carlos, what a nice nice Homepage!
At the moment I work on a caching system which would allow DPL results to be stored and retrieved. I hope to improve performance so that DPL could be used on real large encyclopedias like Wikipedia. Would you like to help testing? Gero 05:52, 19 May 2009 (UTC)
- Hi Gero, and thanks for the invite! This would be a really nice and useful feature, you may count on me to help testing it. Post here whatever code you want tested (or a link to the page where I can find it) and I'll try to return with the results and any bug report in a timely manner. Regards, Capmo 17:17, 19 May 2009 (UTC)
DPL Cache - ideas & question
- Definitions:
- A wiki page which contains one or more invocations of DPL is called a DPL-page in the following text.
- A page containing pre-fabricated DPL results is called a cache page.
- A page which is part of the DPL result (because its name or content appear within the DPL result) is called data page.
- Cache Levels:
- closest to the user there is the browser's cache. It depends on expiration hints given in the http header (which in turn is generated by the MW core system on the server side)
- next comes the MW parser cache. By default this feature is ENabled on newer MW installations. If not explicitly disabled within the php code of the DPL extension the parser cache uses cached content to retrieve a page - which means that the DPL extension is not invoked at all.
- third comes the cache level I think about. If the DPL extension is invoked it uses its own strategy to decide whether it should generate output by querying the database or whether it can use older results instead.
Basically my idea is based on the fact that DPL internally produces regular wikitext in a first step.
- Normally this wikitext is returned by DPL to the parser and thereafter it is transformed to HTML together with all the other wiki text from the DPL page, from included templates etc.
- I want to offer a new option (dplcache=<articlename>) which will save the wikitext portion generated by DPL to an arbitrary wiki cache page (in parallel to returning this output to the parser). The user can specify the name of the cache page according to his own ideas; typically it should be a page in the Template namespace; its name could be derived from the DPL page. For a DPL page named Xyz the cache page might be named Template:Extension DPL/Xyz. If a DPL page contains more than one invocation of DPL (which can happen in rare cases) the user must specify different names because we need a separate cache page for each DPL invocation.
- Whenever the DPL page is viewed, DPL checks if the according cache page exists. If it exists DPL will NOT do its normal work; instead it will simply generate a template inclusion for the cache page. Thus the parser will care for including the previously generated DPL result from the cache page.
- The user can specify an expiration time for the cache page (dplcachetime=<timespan in seconds>). If the cache page is too old, it will be updated when the page containing the DPL statement is viewed after the dplcachetime has passed.
I have a prototype which "in principle" works as described above. But there are a lot of problems still to be solved. One of them is the following:
- If somebody changes the DPL page we do not know if the DPL statement was changed or some other code on the DPL page. To be on the safe side we can always ignore the cache. BUT: HOW do we know that the page is being EDITED, PREVIEWED or simply SHOWN? If the page is only shown we want the cache to be active, if it is being saved we want to update the cache, if it is previewed in edit mode we simply want to ignore the cache.
Do you know how the php code of a MW extension can find out in which mode (DISPLAY, EDIT/SAVE, EDIT/PREVIEW) it is being called?
Another problem is the following:
- Even if the cache time is over it might not be necessary to regenerate the DPL result because it logically depends on the existence and content of the data pages.
A third problem:
A user who changed one of the data pages might want to explicitly trigger a cache-update. This means that he should be made aware of the connection between the DPL page and the data page he is editing.
Gero 19:39, 19 May 2009 (UTC)
