[Grok-dev] Re: Keeping indexes up to date

[Martijn Faassen]

Philipp von Weitershausen wrote:
> On 13 Aug 2007, at 14:10 , Martijn Faassen wrote:
>> I was not discussing this particular case. In many cases this is going
>> to be fairly easy to accomplish. In other cases it's going to make the
>> developer think quite hard - importing the contents of an object from
>> XML may be an example. Any code that isn't form-driven is going to be
>> an example. We'd be asking people to think extra hard, write more
>> code, and so on, while it likely has *no* effect on their system
>> whatsoever. The catalog indeed *completely* ignores this information.
> 
> Right now it does ignore, but I've tried to write a catalog that 
> performs better by NOT ignoring this information (in the end it couldn't 
> be done because zope.formlib and others, alas, don't send the info).

Right. Your argument to do this will be stronger once the catalog starts 
using this information. How much stronger is debatable - it might not 
really gain much performance at all, or might even in some cases *slow* 
down the system to do this (as figuring out what changed takes time and 
might take more time than is saved in the catalog). The only way to find 
out is to do do measurements.

> Also, the catalog is just one possible subscriber. The idea of events is 
> that they're a great way to separate concerns. You're making assumptions 
> about other concerns by arguing that the information is useless.

I'm not arguing the information is useless under all potential 
circumstances. I'm arguing the information is currently not used 
anywhere and telling people to send this information is therefore 
telling people to do useless work. If a particular code base has 
subscribers which can make use of this information, developers should 
send this information along, of course. But that's up to the developers 
of that code base.

>> This is inviting people to do cargo-cult programming: "yeah, I put
>> this in as I saw it in other code and I have no idea why but it
>> works."
> 
> Oh please. 

Oh please? :)

> This is a matter of documentation. And in the worst case, 
> they won't send along the information, so that all subscribers will have 
> take their best guess and e.g. rebuild all indexes, UI elements, etc...

Well, currently nothing is documented at all. I think we shouldn't 
emphasize this story too much in our documentation, as:

* it's more to explain.

* more mistakes can be made by developers.

* there's currently no point to actually doing so.

Grok is about a shifting of the balance: even if there is a reason to do 
some extra work, the drawbacks of doing the extra work may outweigh the 
benefits. Pervasive security proxies providing security by default is an 
example of a reason to do more work that we decided against. External 
explicit configuration is another reason to do more work that we decided 
against.

In this case, there are *no* practical benefits. There is no part of the 
framework that is helped if we provide this information. I'd therefore 
say this is an excellent candidate saying the drawbacks (extra work) 
outweigh the gain (potential benefits in the future).

Once a part of the framework actually starts using this information and 
it can be demonstrated to have practical benefits, *then* you should 
tell people that they may want to start saying explicitly which 
attributes changed. You can then tell them why.

You could say "if only everybody did this, we would be able to do cool 
stuff" but:

* major benefits haven't been convincingly demonstrated yet, at least to me.

* the people who you do convince may end up doing it buggily (as there 
is no difference either way). That's not helping the subscriber author, 
or the people who send these broken events.

* you'll never get everyone to do it anyway as doing so has an increased 
cost above not doing it. Sometimes a small cost, sometimes a larger one.

Regards,

Martijn