Steps missing:

• Move wikibase.AbstractedRepoApi, wikibase.RepoApi to wikibase.api (not wikibase.RepoApiError!)
• (Optional: Remove mw dependency in wikibase.(api.)RepoApi by removing _logFailure)
• Move wikibase.api.* to own extension and git repository

\o/

After a good amount of code restructuring, I now want to start on determining what actually belongs to this soon-to-be API module.

From my point of view, the module could look like the following:

wikibase.api = {

__namespace
FormatValueCaller
getLocationAgnosticMwApi
ParseValueCaller
RepoApi
RepoApiError

}

wikibase.api.tests = {

RepoApi
RepoApiError

}

It would depend on the following resource loader modules:

• json
• mediawiki.api // For wikibase.api.getLocationAgnosticMwApi
• util.inherit
• wikibase // For the namespace

And use the following messages:

• wikibase-error-unexpected (also used by jquery.wikibase.linkitem and Wikibase\Lib\Localizer\GenericExceptionLocalizer)
• wikibase-error-save-generic
• wikibase-error-remove-generic
• wikibase-error-save-timeout
• wikibase-error-remove-timeout
• wikibase-error-ui-edit-conflict

Open questions / tasks:

• What to do with the shared message? Should we duplicate it and define our own version in the JavaScriptApi module, or should we use it without defining it?
• Move wb.RepoApi{,Error} to wb.api

What do you think, Henning, Tobi?

I would not go for message dependencies across module borders--I would opt for duplicating the message.
Will there ever be something like wikibase.api.ClientApi and a ClientApiError or can we get rid of the "Repo" prefix?

I thought the "Repo" would refer to the fact that it works on the API of the Repo.

• wikibase // For the namespace

Where is that defined? If in wb.git, then we'll have a circular dependency no?

I would not go for message dependencies across module borders--I would opt for duplicating the message.

Agree. Else you again create a dependency in the wrong direction. If you where to not duplicate them, then putting them in the component that the other one depends on is better.

Will there ever be something like wikibase.api.ClientApi and a ClientApiError or can we get rid of the "Repo" prefix?

As Adrian noted, the software that provides to used web API is Wikibase Repository. Wikibase Client already has some web API and Wikibase Query will as well. Plus additional things part of Wikibase might have a web API at some point.

What you could of course do is make the interface of the component more abstract and no name it after the implementation of its interface. For instance, you could name it something like "entity store", if what it does is entity persistence. Since I do not know this code, I can't say if it makes sense to have this as public interface of this package, or rather have the interface in whatever talks to this component.

Yes, right now we have circular dependencies with all our Wikibase JS components, because ›wikibase‹ is not just a namespace right now and can't be created on demand. I'm working on removing all properties and state from ›wikibase‹, though.

Good news: with https://gerrit.wikimedia.org/r/171518, wikibase can be used as a namespace and everybody can just initialize it to an empty object if they need to.

https://gerrit.wikimedia.org/r/172522 moves RepoApi to wb.api

Still have to do the message duplication and removal of dependency on 'wikibase' resource loader module.

Change 175987 had a related patch set uploaded (by Adrian Lang):
move wikibase.api into own module

https://gerrit.wikimedia.org/r/175987

Patch-For-Review

Change 175987 merged by jenkins-bot:
move wikibase.api into own module

https://gerrit.wikimedia.org/r/175987