The global Status is still there. But Service and its derived objects
avoid the singleton lookup.
There are likely a few lingering tests that reference Status when they
should reference Service.status. These will be dealt with when Status is
refactored.
This is mostly minor cosmetic changes. Weave was being exported from
service.js for no apparent reason. It was mostly used by tests.
There was a reference to it in engines.js, which should have been caught
when the engines were associated with a service instance. engines.js now
does the right thing.
Weave is no longer exported by service.js. Tests and modules no longer
import main.js.
WeaveSvc was also renamed to Sync11Service because why not.
Weave continues to be the main public API.
The Identity singleton is going away. This refactors SyncStorageRequest
to not use it. Behavior now works like Resource. Instances are obtained
from the Service singleton and have authentication functionality
attached.
Resource currently relies on the Identity singleton to perform
authentication. This is bad magic behavior. Resource instances should
authenticate according to the service instance they are associated with.
This patch removes Identity magic from Resource. Everything using
Resource now explicitly assigns an authenticator which comes from
the service instance/singleton. This required API changes to Collection
and Record.
The preferred method to obtain a Resource instance is to call
getResource() on a service instance.
The end result of this patch looks a little weird, especially in test
code. You have things like Service.resource(Service.cryptoKeysURL).
This ugliness will go away when a unified storage service client is
used.
Engines now maintain a reference to the service they belong to. This
allows them to obtain references to other engine instances belonging to
that service and that service only.
Stores and trackers now maintain a reference to the engine they belong
to.
Engine managers now maintain a reference back to a service.
The clients singleton has been removed. It now exists as an instance
variable on Service. Parts of ClientsEngine do behave as singletons
(e.g. commands). This will be addressed in future refactoring.
Clients was being exported and used as a singleton. We still use Clients
as a singleton in some places, but only in test code. The preferred
method to access Clients is now through a service instance.
Weave.Clients is no longer exposed. Callers go through Weave.Service
now.
Lots of exports from the Weave global object weren't being used. This
also changes how engines are loaded. There is now a mapping in
service.js of engine name to filename. Before, it was looking at Weave.
Some tests still expect there to only be a single instance of
ErrorHandler for the life of the tests. And, ErrorHandler itself is
pretty tighly coupled with being a singleton because it writes out
changes to prefs, etc. But, it's a step in the right direction.
