Just a note regarding all the cache discussions.<br><br>I will be in Portland next week for O'Reilly's Open Source.<br><br>If anyone is attending, we can do some collaboaration and testing.<br><br>I will be in town Tuesday through Saturday.
<br><br>- Ken<br>agentrickard at <a href="http://gmail.com">gmail.com</a><br><br><br><div><span class="gmail_quote">On 7/23/06, <b class="gmail_sendername"><a href="mailto:development-request@drupal.org">development-request@drupal.org
</a></b> <<a href="mailto:development-request@drupal.org">development-request@drupal.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Send development mailing list submissions to<br> <a href="mailto:development@drupal.org">development@drupal.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://lists.drupal.org/listinfo/development">
http://lists.drupal.org/listinfo/development</a><br>or, via email, send a message with subject or body 'help' to<br> <a href="mailto:development-request@drupal.org">development-request@drupal.org</a><br><br>You can reach the person managing the list at
<br> <a href="mailto:development-owner@drupal.org">development-owner@drupal.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of development digest..."
<br><br><br>Today's Topics:<br><br> 1. GNOME's CMS evaluation for Drupal (Andy Smith)<br> 2. Re: Object caching (Larry Garfield)<br> 3. Re: Caching, caching, caching... (Gordon Heydon)<br><br><br>----------------------------------------------------------------------
<br><br>Message: 1<br>Date: Sun, 23 Jul 2006 03:31:29 +0200<br>From: "Andy Smith" <<a href="mailto:andyster@gmail.com">andyster@gmail.com</a>><br>Subject: [development] GNOME's CMS evaluation for Drupal<br>
To: <a href="mailto:development@drupal.org">development@drupal.org</a>, <a href="mailto:documentation@drupal.org">documentation@drupal.org</a><br>Message-ID:<br> <<a href="mailto:541901410607221831i320e2153x8aed0777fe7b84a7@mail.gmail.com">
541901410607221831i320e2153x8aed0777fe7b84a7@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Hey folks, GNOME is looking to change to a CMS and since I like GNOME I'd<br>obviously like it to choose a very nice CMS like Drupal, however when I
<br>looked at the page plenty of data appeared to be incomplete, things like<br>i18n and such that people have less knowledge about, but maybe some of you<br>can fill it in<br><br><a href="http://live.gnome.org/GnomeWeb/CmsRequirements/DrupalEval">
http://live.gnome.org/GnomeWeb/CmsRequirements/DrupalEval</a><br><br>If you are interested in the GNOME project using Drupal, head to that link<br>and give some factual info.<br><br>--andy<br>-------------- next part --------------
<br>An HTML attachment was scrubbed...<br>URL: <a href="http://lists.drupal.org/pipermail/development/attachments/20060723/324a380b/attachment-0001.htm">http://lists.drupal.org/pipermail/development/attachments/20060723/324a380b/attachment-0001.htm
</a><br><br>------------------------------<br><br>Message: 2<br>Date: Sat, 22 Jul 2006 23:30:02 -0500<br>From: Larry Garfield <<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>><br>Subject: Re: [development] Object caching
<br>To: <a href="mailto:development@drupal.org">development@drupal.org</a><br>Message-ID: <<a href="mailto:200607222330.02425.larry@garfieldtech.com">200607222330.02425.larry@garfieldtech.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"
<br><br>On Saturday 22 July 2006 16:19, Khalid B wrote:<br><br>> I don't think it is bad denormalization in this case.<br>><br>> What we have now is a one to many relationship of node -> alias, and<br>> we allow multiple aliases for the same node.
<br>><br>> If we go to a 1:1 relationship, then the logical place for the alias is in<br>> the object that it represents (term, user, node), and this would speed<br>> up things for certain operations (e.g. emitting an alias instead of
<br>> the native path), but potentially slow others (looking up an incoming<br>> alias and converting to the native path?)<br>><br>> What we lose here is the ability for multiple aliases.<br><br><br>I don't see how we do. It just declares one alias "primary".
<br><br>That is, if node 5 has an alias of my/fifth/node in the node table, that is<br>the alias that is used for any output. Vis, system-generated links to node/5<br>are always rewritten to my/fifth/node.<br><br>The separate alias table then is for *incoming* paths. You can have as many
<br>aliases for a page as you want for incoming requests, but only one for Drupal<br>output. (And really, why would you want to have multiple aliases that get<br>printed by Drupal? That only confuses people.)<br><br>As an example, suppose you have a weekly newsletter, with each newsletter
<br>being a node. The alias for each newsletter would be its date, say<br>newsletter/2006-07-22. That's the primary alias, and that's in the node<br>table. Then there's also an alias newsletter/latest that points to whichever
<br>is most recent (updated however), which you can put into mailings and such.<br>Once the user's there, however, there's no reason to not send them to the<br>dated alias.<br><br>So we're not losing multi-alias support at all, at least not really.
<br><br>--<br>Larry Garfield AIM: LOLG42<br><a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a> ICQ: 6817012<br><br>"If nature has made any one thing less susceptible than all others of
<br>exclusive property, it is the action of the thinking power called an idea,<br>which an individual may exclusively possess as long as he keeps it to<br>himself; but the moment it is divulged, it forces itself into the possession
<br>of every one, and the receiver cannot dispossess himself of it." -- Thomas<br>Jefferson<br><br><br>------------------------------<br><br>Message: 3<br>Date: Sun, 23 Jul 2006 19:48:37 +1000<br>From: Gordon Heydon <
<a href="mailto:gordon@heydon.com.au">gordon@heydon.com.au</a>><br>Subject: Re: [development] Caching, caching, caching...<br>To: <a href="mailto:development@drupal.org">development@drupal.org</a><br>Message-ID: <<a href="mailto:44C345F5.5080804@heydon.com.au">
44C345F5.5080804@heydon.com.au</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Hi,<br><br>Remember also modules like organic groups which has no relation to roles.<br><br>Maybe a caching flag on theme('page'), so the modules can determine tell
<br>the system to cache this page for this user, or groups of users.<br><br>I know that we just return something, so we would need to make the<br>return method to allow the returning of an array which is past to<br>theme('page');
<br><br>Gordon.<br><br>John Handelaar wrote:<br>> Dries Buytaert wrote:<br>>><br>>> Cache by role doesn't work because there are many per-user settings<br>>> (eg. language preference, the username in the navigation-block, etc).
<br>><br>><br>> To be fair, I did *explicitly* mention that would be some<br>> elements which could not be cached by role.<br>><br>> There are, however, a whole bunch which can - I'm confident<br>> in my original assertion of 'vast majority', in fact.
<br>><br>> That there are some places it can't work doesn't sound like<br>> a good reason to not consider the places where it can -<br>> unless we're going to keep thinking of caches as a full-page-<br>> only thing.
<br>><br>> i18n/l10n, as you say, would probably have to be another "vary"<br>> switch. This implies that we should maybe be thinking about<br>> a new core hook, which modules can use to introduce/manage switching
<br>> cases.<br>><br>> How about stepping back and thinking about what variables can<br>> affect caching on any given theme() function, and in which order<br>> they do so?<br>><br>> eg<br>><br>> 1. (core) Role, and if not role then
<br>> 2. (core) User, and if not user then<br>> 3. (i18n module) $some_i18n_variable, else<br>> 4. ...what else?<br>><br>><br>> Actually, that list might be upside down in practice, but<br>> hopefully I've managed to get my point across.
<br>><br>><br>> Cached values would be returned for any function which<br>> returns theme output... like...<br>><br>> [pseudo-code]<br>><br>> function node_page_default() {<br>> global $user;<br>
> if (node_page_default_cache($user->uid)) {<br>> return node_page_default_cache($user-uid);<br>> }<br>> else {<br>><br>> // original function here<br>><br>> }<br>> }
<br>><br>> ...where node_page_default_cache() would be an implementation<br>> of hook_cache(), which in turn contains that order-of-preference<br>> logic mentioned above. $user->uid gives us the ability to
<br>> check roles, uids, and anything else we might need.<br>><br>> This would involve changing *lots* of functions, I realise,<br>> but consider how many DB queries we'd be culling.<br>><br>> On the other hand, a well-written hook allows modules to
<br>> start using it incrementally - modules which haven't implemented<br>> it yet don't fail.<br>><br>><br>><br>><br>><br>><br><br><br>------------------------------<br><br>--<br>[ Drupal development list |
<a href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]<br><br>End of development Digest, Vol 43, Issue 87<br>*******************************************<br></blockquote></div><br>