On Tue, Sep 1, 2009 at 2:16 PM, Domas Mituzas<midom.li...@gmail.com> wrote:
> Hello,
>
>> What other people have objected is your position that the only way to
>> regain them is to manually replace {{SITENAME}} on all messages.
>
> I didn't say "manually" ;-) One could have an automated solution :)
>
>> Parser->transformMsg() could replace many well-known "{{something" and
>> only call preprocess if there's still some "{{".
>> It probably means refactoring getVariableValue() and some change at
>> CoreParserFunctions or mFunctionHooks, to not make it too ugly, but it
>> can be done.
>
> I find it remarkable that you want to introduce that much of
> obfuscation for something, what has been resolved for past few years ;-)
> Do note, that such code would need to be maintained for all the
> possible cases, would probably fail with certain grammar issues in
> some messages, and, dear oh dear, may not really work with
> internationalized magicwords ;-)
> Is that code going to be much faster?
>
>> The parser initialization is also quite expensive, but since the
>> parser
>> will end up being used, I think we can omit it.
>
> This is very wrong assumption. Parser is not being used in most
> article pageviews (e.g. article text is parsed on about 7% of requests
> to backend, of course there're quite a few Parser calls by search,
> diffs, etc).

As I suggested yesterday, perhaps not very clearly, I think the
sensible thing to do is to bypass the Parser on most calls to messages
like "Welcome to {{SITENAME}}" by caching the post-transformed version
of the message, e.g "Welcome to Wikipedia", in the MessageCache
instead.  This should be possible if the message has no context
dependent substitutions (e.g. if the message avoids things like
substitution variables and context dependent magic words like
{{NAMESPACE}}).

It would mean teaching the parser to look for context dependent
elements and having some way to communicate that to the MessageCache
to allow it to decide whether to cache the pre-transformed or
post-transformed version.  It would also mean categorizing magic words
to identify whether caching is allowed, but that seems like a
straightforward extension of the TTL hinting already done in
MagicWord.  The magic word caching hints could also be used to help
decide how long the post-transformed version is likely to be good for.

More importantly, it avoids the pitfalls of trying to reintroduce
parser logic in transformMsg or some other preliminary step.

-Robert Rohde

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to