bind something to PeerManager.class will result in initialization failure.
A system that uses the peer services needs to extend PeerManager or
CrowdPeerManager with a concrete PeerManager and then
bind(PeerManager.class).to(SomePeerManager.class) to properly satisfy the
dependency.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5171 542714f4-19e9-0310-aa3c-eee0fc999fb1
dependencies into both. Moved the legacy statics into CrowdServer so that at
least Presents can be pure (we should probably eventually move them into
BangServer and PiracyServer and fix everything else). Added some useful manager
references to PlaceManager delegate (_omgr, _invmgr) that handle the majority
of their service needs.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5170 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Inject the auth Invoker.
- Inject the Authenticator and formalize the chaining authenticator pattern.
- Simplify PeerNode creation and make the PeerAuthenticator a chainer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5162 542714f4-19e9-0310-aa3c-eee0fc999fb1
dependency resolution and management. Things are currently in a state of
transition, but the important patterns have been established and I'll aim to
sweep through all of Narya, Nenya and Vilya in the near future and do
everything properly.
Going through the other million-odd lines of code we have scattered across our
various projects that use these libraries is not something I plan to do, so
we'll be maintaining backward compatibility with the old static member method,
though I hope to strive toward eradication of that usage entirely in MSOY while
we still have a fighting chance.
Given that some of our projects will continue to use the static member method
in perpetuity, I'm not going to @Deprecate those fields because that would fill
their logs with so much spam that they'd have to turn off deprecation warnings
which would make life worse for them. So instead we'll settle for the big scary
comment warning people away from the old bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5153 542714f4-19e9-0310-aa3c-eee0fc999fb1
servers for execution. The class in question must exist on the remote server
but all of our servers are all always running the same code, so this follows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4882 542714f4-19e9-0310-aa3c-eee0fc999fb1
configuration information to other peers so that they all remain in sync.
Also nixed constructor arguments to the peer manager so that it can be created
at server construct time like all other managers and be available for the
twisty maze of inter-registration that takes place during the manager init
process.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4814 542714f4-19e9-0310-aa3c-eee0fc999fb1
distributed object space so that the unsubscribe from the remote server is
properly handled.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4787 542714f4-19e9-0310-aa3c-eee0fc999fb1
encapsulate it into a mechanism that takes care of the trickiness for us.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4770 542714f4-19e9-0310-aa3c-eee0fc999fb1
dangerous with two big inner helper classes. Added the nodeName to NodeObject
and some other handy methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4767 542714f4-19e9-0310-aa3c-eee0fc999fb1
lose connection with a peer for any reason, it will notice that we're still
alive and reconnect.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4732 542714f4-19e9-0310-aa3c-eee0fc999fb1
and the ProxySubscriber mechanism by which the server proxies for the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4730 542714f4-19e9-0310-aa3c-eee0fc999fb1
another server. The PeerManager needs both to rewrite the oid of the events
before dispatching them and to assign an eventId to them so that they will not
be filtered by PresentsClient when deciding whether or not to send them along
to its client. Also fixed compound event dispatch in the process. Now proxy
subscribers will be notified once of a compound event rather than of each
individual internal event.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4729 542714f4-19e9-0310-aa3c-eee0fc999fb1
been disconnected (in which case there may be conflicts in lock
ownership) or are connected asymmetrically (A is subscribed to B, B is
not yet subscribed to A).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4674 542714f4-19e9-0310-aa3c-eee0fc999fb1
objects to non-modifiable, restrict client object subscriptions to the client
in question). Modified Peer code to not log a warning when a peer is not online
in an expected way (not listening for connections).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4598 542714f4-19e9-0310-aa3c-eee0fc999fb1
peer sign-on to be the connecting server's node name.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4580 542714f4-19e9-0310-aa3c-eee0fc999fb1
Take the lock immediately if there are no subscribers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4576 542714f4-19e9-0310-aa3c-eee0fc999fb1
notion of a global group (though we implicitly define one in InvocationCodes)
added a mechanism for directors (which generally handle the client side of
invocation services) to register their interest in bootstrap service groups so
that the whole goddamned complex business can happen magically behind the
scenes.
If you instantiate a director, it will automatically register interest in the
service group it needs and everything will work. If you don't use the director
code, you don't get the services and you can safely exclude all of that code
from your client even though the services are still in use on the server (and
presumably used by some other types of clients).
This is going to break all the builds, which I'll soon fix. Then I'll go write
all this in ActionScript. Yay!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4552 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne