Open BurntSushi opened 10 years ago
Such a change would be highly plausible and acceptable! Most non-pywikibot editing tools I've seen have been very one-off, so Stephen and I just assumed adding editing as part of the roadmap since very early on. It just ended up always prioritized lower than read operations (mostly because of https://github.com/mahmoud/womp). So I guess my first question would be, when?
The steps you've described are basically accurate. There should be a login operation, which unless passed "anonymous" credentials, the client would use to log in before executing other operations.
Wapiti is actually targeted at multi-step and fan-out operations, though they could be structured a lot better for edits (i.e., made more transactional/atomic and making the root Operation could be more generic).
Lately I've been working on enabling parallel Operations, generifying Operation, and adding logging. At the very least we could list out some use cases and do some design. Wapiti is sort of a DSL for translating Wikipedia APIs to Python, so the developer interface definitely matters. One potential hurdle I see is that all the current operations have a "main" parameter, which works well for almost all the query operations, but i haven't looked into what it means for editing.
Anyways, how does all of that sound?
I was thinking about extending
wapiti
to allow for editing content and I wanted to get your opinion on it.Firstly, would you be open to accepting such a change?
Secondly, after a brief perusal of the source code, here's what I think needs to happen:
WapitiClient
needs to support logging into an existing account.Operation
framework you've built up would need to be taught about two step operations (request an edit token if one hasn't already been delivered, block all requests requiring said token and then launch those requests when the token arrives).Does that sound remotely plausible?
P.S. The only tool I'm aware of that really supports editing is
pywikibot
. Do you know of any others?