On 7/23/06, development-request@drupal.org <development-request@drupal.org> wrote:

Send development mailing list submissions to
        development@drupal.org

To subscribe or unsubscribe via the World Wide Web, visit
         http://lists.drupal.org/listinfo/development
or, via email, send a message with subject or body 'help' to
        development-request@drupal.org

You can reach the person managing the list at
        development-owner@drupal.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of development digest..."

Today's Topics:

   1. GNOME's CMS evaluation for Drupal (Andy Smith)
   2. Re: Object caching (Larry Garfield)
   3. Re: Caching, caching, caching... (Gordon Heydon)

----------------------------------------------------------------------

Message: 1
Date: Sun, 23 Jul 2006 03:31:29 +0200
From: "Andy Smith" <andyster@gmail.com>
Subject: [development] GNOME's CMS evaluation for Drupal
To: development@drupal.org, documentation@drupal.org
Message-ID:
        < 541901410607221831i320e2153x8aed0777fe7b84a7@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hey folks, GNOME is looking to change to a CMS and since I like GNOME I'd
obviously like it to choose a very nice CMS like Drupal, however when I
looked at the page plenty of data appeared to be incomplete, things like
i18n and such that people have less knowledge about, but maybe some of you
can fill it in

http://live.gnome.org/GnomeWeb/CmsRequirements/DrupalEval

If you are interested in the GNOME project using Drupal, head to that link
and give some factual info.

--andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060723/324a380b/attachment-0001.htm

------------------------------

Message: 2
Date: Sat, 22 Jul 2006 23:30:02 -0500
From: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [development] Object caching
To: development@drupal.org
Message-ID: <200607222330.02425.larry@garfieldtech.com>
Content-Type: text/plain;  charset="iso-8859-1"

On Saturday 22 July 2006 16:19, Khalid B wrote:

> I don't think it is bad denormalization in this case.
>
> What we have now is a one to many relationship of node  -> alias, and
> we allow multiple aliases for the same node.
>
> If we go to a 1:1 relationship, then the logical place for the alias is in
> the object that it represents (term, user, node), and this would speed
> up things for certain operations (e.g. emitting an alias instead of
> the native path), but potentially slow others (looking up an incoming
> alias and converting to the native path?)
>
> What we lose here is the ability for multiple aliases.

I don't see how we do.  It just declares one alias "primary".

That is, if node 5 has an alias of my/fifth/node in the node table, that is
the alias that is used for any output.  Vis, system-generated links to node/5
are always rewritten to my/fifth/node.

The separate alias table then is for *incoming* paths.  You can have as many
aliases for a page as you want for incoming requests, but only one for Drupal
output.  (And really, why would you want to have multiple aliases that get
printed by Drupal?  That only confuses people.)

As an example, suppose you have a weekly newsletter, with each newsletter
being a node.  The alias for each newsletter would be its date, say
newsletter/2006-07-22.  That's the primary alias, and that's in the node
table.  Then there's also an alias newsletter/latest that points to whichever
is most recent (updated however), which you can put into mailings and such.
Once the user's there, however, there's no reason to not send them to the
dated alias.

So we're not losing multi-alias support at all, at least not really.

--
Larry Garfield                  AIM: LOLG42
larry@garfieldtech.com          ICQ: 6817012

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it."  -- Thomas
Jefferson

------------------------------

Message: 3
Date: Sun, 23 Jul 2006 19:48:37 +1000
From: Gordon Heydon < gordon@heydon.com.au>
Subject: Re: [development] Caching, caching, caching...
To: development@drupal.org
Message-ID: < 44C345F5.5080804@heydon.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

Remember also modules like organic groups which has no relation to roles.

Maybe a caching flag on theme('page'), so the modules can determine tell
the system to cache this page for this user, or groups of users.

I know that we just return something, so we would need to make the
return method to allow the returning of an array which is past to
theme('page');

Gordon.

John Handelaar wrote:
> Dries Buytaert wrote:
>>
>> Cache by role doesn't work because there are many per-user settings
>> (eg. language preference, the username in the navigation-block, etc).
>
>
> To be fair, I did *explicitly* mention that would be some
> elements which could not be cached by role.
>
> There are, however, a whole bunch which can - I'm confident
> in my original assertion of 'vast majority', in fact.
>
> That there are some places it can't work doesn't sound like
> a good reason to not consider the places where it can -
> unless we're going to keep thinking of caches as a full-page-
> only thing.
>
> i18n/l10n, as you say, would probably have to be another "vary"
> switch.  This implies that we should maybe be thinking about
> a new core hook, which modules can use to introduce/manage switching
> cases.
>
> How about stepping back and thinking about what variables can
> affect caching on any given theme() function, and in which order
> they do so?
>
> eg
>
> 1.  (core) Role, and if not role then
> 2.  (core) User, and if not user then
> 3.  (i18n module) $some_i18n_variable, else
> 4.  ...what else?
>
>
> Actually, that list might be upside down in practice, but
> hopefully I've managed to get my point across.
>
>
> Cached values would be returned for any function which
> returns theme output... like...
>
> [pseudo-code]
>
> function node_page_default() {
>   global $user;
>   if (node_page_default_cache($user->uid)) {
>      return node_page_default_cache($user-uid);
>      }
>      else {
>
>      // original function here
>
>      }
> }
>
> ...where node_page_default_cache() would be an implementation
> of hook_cache(), which in turn contains that order-of-preference
> logic mentioned above.  $user->uid gives us the ability to
> check roles, uids, and anything else we might need.
>
> This would involve changing *lots* of functions, I realise,
> but consider how many DB queries we'd be culling.
>
> On the other hand, a well-written hook allows modules to
> start using it incrementally - modules which haven't implemented
> it yet don't fail.
>
>
>
>
>
>

------------------------------

--
[ Drupal development list | http://lists.drupal.org/ ]

End of development Digest, Vol 43, Issue 87
*******************************************