Rationale

• Easier, uniform access to wiki using XML, much less prone to break in case of changes than plain HTML
• Potentially much faster, should save bandwidth considerably
• Would allow to minimise WebBrowser usage - less bugs, faster processing due to elimination of in-place DOM magic; also should make AWB much more portable (I suppose that Mono supports the basic WebBrowser crap we need to display previews and diffs - MaxSem)

Current write API status

Horribly immature: not tested widely enough, not fully reviewed security-wise, not enabled on any Wikimedia projects other than testwiki, even the older query functions are still subject to breaking changes.

Enabled now, some problems remain.

We cannot release even a beta until it's enabled everywhere and included in a quarterly MW release, signifying some level of stability. (At least four to six months from now? - MaxSem)

Important bugs

• 14210: Activate write API on production wikis (kinda tracking) fixed
• 14261: More information in hookaborted API error needed - blocking issue for our purposes
• 14443: successful edit causes server to return HTTP 500 fixed
• Search all API-related issues

Current progress on AWB side

~90% - logging in/out, editing, deletion and a semi-functional skeleton of asynchronous wrapper.

Things to be done

AWB

I assume that API editing should be made available as of version 5.0. -MaxSem

• Development should be continued as usual
• YApiEdit should be finished and maintained
• YSupport for nested exceptions should be added to ErrorHandler - done in rev 2911
• YWe could test API further right now by swithching to API-based previews, for example
• Political choice: session persistance
  • We should probably store cookies, just like IE does in our current scheme
  • Or make AWB completely profile-dependant?
    • Could work, but would all users be "happy" saving their passwords somewhere..? — Ree dy 09:47, 13 June 2008 (UTC) reply
  • And move profiles away from registry?
    • Storing where is safer?

      Registry was deemed one of the safer places, easily accessible, and meant that users didn't inadvertently send someone their profile, and were there for any settings loaded by that user on that computer. — Ree dy 09:47, 13 June 2008 (UTC) reply

      If we store them in Application Data, accidental uncovery would be unlikely... MaxSem^{( Han shot first!)} 11:08, 13 June 2008 (UTC) reply

  • And encrypt profiles with a master password?

• YNormalise API usage in GetLists, by making it completely dependant on ApiEdit to retrieve data from the site and check the results for errors
  • Somewhat done. GetLists Modulised by Reedy, and then commonised by MaxSem
• Write a thread-based wrapper for ApiEdit to use in interface
• YYYKill WebControl with fire
• YPhase out the old editor class, probably not worth deleting it
• Make a branch of old-style AWB for usage by people from third-party wikis running older versions of MW. This branch shouldn't be able to edit Wikimedia sites. As such, we don't need it to follow the version checkpage. Its ErrorHandler shouldn't advice people to post every exception to WP:AWB/B, too.
• Release 5.0 and prepare enough vaseline when people will start reporting bizarre bugs o_0

AWBUpdater

• Make it copy every file from .zip, not just every file it knows, as it is currently. Fixed
• Take extra precautions that people don't use older updater.
• Make it update even if AWB.exe is corrupt or not present.
• Handle present plugins on update (delete? quarantine? automatically? ask user?). Probably, we could even use reflection to detect obviously outdated ones.

Implementation details

Editing classes

• Don't use those dreaded singletons like WikiFunctions.Variables, they're hopelessly screwed up. Also, people should be able to reuse ApiEdit without having long sexual intecourse with AWB-specific stuff. Remember, Variables constructor can be called from zillion places without you even noticing this.