hi Daniel,
thanks for the clarifications. Indeed I didn't read properly
the entire document and therefore I was reading the first
passage merely from the perspective of the hook dispatcher / hook
handler perspective, while now I see the concern to minimize
the transactions exposed to the client. (at macroscopic level, so to say)
With regard to the second point "This clarifies the semantics of extension
callbacks invoked as a result of a change, particularly with respect to
transactional context."
it also makes complete sense when you are familiar with the topic (of after
the explanation) I don't know if there is a way to reword it for newcomers,
possibly not, at least as a list item.
In general I was aware of the efforts to apply Domain-Driven Design
methodologies
to tackle the intricacies of the current code-base however I do not think there
is
a way to simplify MediaWiki in a significant way without reducing its overall
consistency and even potential
(which is the reason why extensions exist) unless indeed you don't increase the
complexity in some other way, as a result indeed of the disambiguation
that I see you (as a team) are doing and which is of course a remarkable work.
So I just want to express my concern about the goal of making of MW or also
Wikipedia,
which as far as I understand is the organic and still on-going outcome
of a community of pioneers, professionals and volunteers, specifically a
"product",
as I have heard in the context of "evolving Wikipedia", which is
something that in my view implies a commercial logic (not fully
compatible with that of community) and especially something
which intrinsically discourages or hinders other uses except those
set or predefined, which again (from a logical point of view)
undermines the rationale for the extensions as something
which complement a software of which Wikipedia is one of
the applications, although the most notable.
Of course I see that the refactoring/redesign work is being carried out
taking all necessary precautions and by qualified people, however in the same
time,
specifically for this reason, wouldn't be preferable to adjust the goal
statement or approach in order to reflect the actual nature of the work
rather than the commercial or administrative perspective ?
Thank you again for the clarifications and all the best
(Thomas)
---- On Tue, 15 Jul 2025 13:55:02 +0100 Daniel Kinzler <[email protected]>
wrote ---
Hi Thomas!
Am Di., 15. Juli 2025 um 13:18 Uhr schrieb Thomas < mailto:[email protected] >:
1) here "Hooks are typically, but not always, invoked synchronously during the
main transaction, while the client waits for a response." -- shouldn't be
rather "while the caller waits" or "where the caller waits" instead of "while
the client waits" if with "client" you mean the hook dispatcher ?
Both, really. If the hook handler (or event listener) is executed synchronously
while the caller waits, that typically also means that the client that made the
web request is still waiting for a response. That's the case because we only
send the web response after the main transaction is complete, otherwise we
would not be able to inform the client about errors.
If on the other hand we delay invocation of the listener until after the main
transaction is complete, we can also defer it until after the response has been
sent to the client, to reduce latency.
The implication is that listeners can be sure that the original change has been
persisted in the database, but it also means that if the listener fails, this
will be invisible to the client.
This behavior is equivalent to what you would get from a hook handler the
schedules a DeferredUpdate, which is already the case for the majority of
handlers that perform database updates.
2) here "Events get delivered to listeners via a DeferredUpdate after the main
transaction was successful and the response has been sent to the client. This
clarifies the semantics of extension callbacks invoked as a result of a change,
particularly with respect to transactional context." do you mean that in case
of events the hook handlers cannot anymore modify the source data before are
saved, if that's needed for any reason ? Can you also clarify more the second
part of the paragraph ?
Yes, event listeners cannot modify data before it is saved. Events are
notifications about things that happened in the past. If you need to intercept
or manipulate an action, you cannot use events, you would just keep using hooks
for that, as before. Hooks that allow for the cancellation of actions or
manipulation of data will not be replaced by events (though we may look into
other ways to make them nicer).
With respect to the invocation semantics, the idea is that events guarantee
that they are *always* invoked only after the transaction is complete, and only
if that transaction is successful. With hooks, there is no such clarity - most
hooks are invoked synchronously, but not all - some are invoked in a
DeferredUpdated. And this may change without notice, it's not documented or
guaranteed. That means that a hook handler that receives e.g. the ID of a newly
inserted revision has no guarantee that the transaction won't be rolled back so
that revision ID would vanish or might even be re-used for a different revision
later.
I hope this clears things up a bit. Feel free to edit the manual pages to make
them more clear, it's a wiki!
-- daniel
_______________________________________________
Wikitech-l mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
_______________________________________________
Wikitech-l mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
