Wikipedia:AutoWikiBrowser/API migration

From Wikipedia, the free encyclopedia

AutoWikiBrowser - 4.3.2.0

v • d • e
Home

General information about AutoWikiBrowser and directions for installation.

 Request approval

Request approval to be added to the CheckPage to use AutoWikiBrowser.

 Discussion

Discuss the application and ask questions.

 Bugs

Report bugs in the application.

 Feature Requests

Request new features to be implemented into AWB

 User manual

The full user manual.
Developer Talk Page · Typos · IW Order · User talk templates · Plugins · IRCMonitor · Projects which have used AWB · Changelog · AWB Sandbox · Settings · Custom Modules · WikiFunctions.dll · Custom style.css · Userbox · SVN Snapshots · Usage Stats

Contents

[edit] Migration to Bot API specs

[edit] 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)

[edit] 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.

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)
  • 14261: More information in hookaborted API error needed - blocking issue for our purposes
  • 14443: successful edit causes server to return HTTP 500
  • Search all API-related issues

[edit] Current progress on AWB side

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

[edit] Things to be done

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

  • Development should be continued as usual
  • ApiEdit should be finished and maintained
  • Check markYSupport for nested exceptions should be added to ErrorHandler - done in rev 2911
  • We 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?
    • And move profiles away from registry?
      • Storing where is safer?
    • And encrypt profiles with a master password?
  • Normalise API usage in GetLists, by making it completely dependant on ApiEdit to retrieve data from the site and check the results for errors
  • Write a thread-based wrapper for ApiEdit to use in interface
  • Kill WebControl with fire
  • Phase out the old editor class, probaly 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

[edit] 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.

[edit] Discussion