to delegates that can handle them. Turns out we already even had this option in
the PlaceController.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5224 542714f4-19e9-0310-aa3c-eee0fc999fb1
extending systems and depended upon by services that need to lookup bodies.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5212 542714f4-19e9-0310-aa3c-eee0fc999fb1
Place manager delegates now store their own references to the omgr and invmgr
and set the members via the init function. This is fine, but due to the order
of calling PlaceManager's init and addDelegate, the PlaceManagerDelegate.init
was receiving null values.
The fix is to provied a more consistent guarantee about the relationship
between init and addDelegate. After both have been called (regardless of
order), we guarantee that both init and didInit have been called on all
delegates.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5177 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
LocationProvider can be an interface like its brothers and sisters.
Modified the place registry to create PlaceManager instances using the injector
so that we can inject dependencies into managers. Also modified the custom
classloader functionality so that it can/will circumvent this process
entirely. It's not possible to inject using a custom classloader and one
certainly would not want to do so.
Unfortunately this means we can't inject some basic managers into PlaceManager
because it needs to work for games loaded into a sandboxed classloader, but the
big win is that in everything other than GameManager and PlaceManager, we can
inject to our heart's content.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5168 542714f4-19e9-0310-aa3c-eee0fc999fb1
I just feel like: imagine if there were no Map.containsKey().
You would instead have to get() the value and see if it's not null.
If you did that, you certainly wouldn't throw away the value if you
were going to get it again right below, would you? So why would
you do it simply because of the addition of a convenient method
called containsKey()?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5067 542714f4-19e9-0310-aa3c-eee0fc999fb1
crowd was intentional (with presents on top because it is more "generic"). We
must resist Eclipse's desire to squish our imports together into one giant,
hard to (visually) parse blob.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5060 542714f4-19e9-0310-aa3c-eee0fc999fb1
rather is configured with it when added to the manager as a delegate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4868 542714f4-19e9-0310-aa3c-eee0fc999fb1
call didShutdown, so we can't stop listening to it until then.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4824 542714f4-19e9-0310-aa3c-eee0fc999fb1
manager can be collected even if the object lingers about for a while and
because it sets a good example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4823 542714f4-19e9-0310-aa3c-eee0fc999fb1
proper interface like all the other new invocation service backends.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4795 542714f4-19e9-0310-aa3c-eee0fc999fb1
be extended to contain the sceneId by Whirled (Vilya's Whirled, though also
Whirled Whirled by extension) so that we don't end up with problems where
BodyObject.location changes but BodyObject.sceneId remains stale. This won't
impact Yohoho because the Yohoho client is always in a scene, it uses a
separate mechanism to track games, whereas Whirled's natural usage is to move
between scenes and non-scenes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4779 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
like Groovy and JRuby. Created a DynamicEventDispatcher that automatically maps
attribute, element and set events to methods. Say you have a field:
public DSet occupantInfo;
you can create a method in any class:
public void occupantInfoAdded (BodyObject source, OccupantInfo entry);
and then bind that class as a listener using the dynamic event dispatcher:
_myobj.addListener(new DynamicEventDispatcher(object));
I also created a nicer replacement for the MessageHandler system which is
clunky but still way simpler than using a full InvocationService. Basically we
dispatch MessageEvent as if it were a method call.
For example, in AtlantiManager I define:
public void placeTile (BodyObject placer, AtlantiTile tile)
which receives a request by a player to place a tile on their turn. Then in
AtlantiController, I simply call:
_atlobj.manager.invoke("placeTile", tile);
Of course, in JRuby and Groovy, that's going to look like:
_atlobj.manager.placeTile(tile);
which is all part of the fun.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4344 542714f4-19e9-0310-aa3c-eee0fc999fb1
distributed objects by reflection since we don't allow clients to create
objects, furthermore we needn't do it asynchronously. The object creation
methods were moved into the server-side only interface and made "immediate", so
the caller creates a derived instance of DObject and registers it with the
system instead of creating it with a Subscriber callback.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4342 542714f4-19e9-0310-aa3c-eee0fc999fb1
Also, while I was in there, added some safety so we don't lose track of shutdownIntervals and let them run amuck.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4295 542714f4-19e9-0310-aa3c-eee0fc999fb1
These are the preferred way to get instances of Boolean, Byte,
Short, Character, Integer, Long, Float, and Double object.
It's always made sense for Boolean objects, and with 1.5 these factory
methods were blessed as the proper way to get instances unless one
absolutely needed a distinct object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4145 542714f4-19e9-0310-aa3c-eee0fc999fb1
PlaceObject. Created a default AccessController that is slightly more strict
than the CrowdServer-wide default in that it only allows place occupants to
subscribe to a PlaceObject (a motivated and resourceful player could otherwise
listen in on place chat everywhere in the game if they so desired; with a
custom client, of course).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4079 542714f4-19e9-0310-aa3c-eee0fc999fb1
- OccupantInfo is created by the BodyObject
- the BodyObject is passed to the OI constructor and it uses information
therefrom to configure itself
- the PlaceManager are no longer responsible for indicating the type of
OccupantInfo to use or how to populate it.
This makes much more sense as the same type of OccupantInfo is generally used
across the entire system and it's annoying to have to have every PlaceMaanger
derived class know the type of OccupantInfo to create and know how to
initialize it. The one drawback is that only information from the BodyObject
can be used to populate the OccupantInfo, unpublished server-side only
information cannot be used (unless its stuffed into a transient field in the
BodyObject).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3774 542714f4-19e9-0310-aa3c-eee0fc999fb1
applicable, as it will only otherwise get checked when users leave the place.
It's possible that we'll load and nobody will ever enter.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3763 542714f4-19e9-0310-aa3c-eee0fc999fb1
as their authentication name (which we leave in BodyObject.username). This
turns out to be simpler than the system we adopted for Yohoho wherein we
replace the player's user object after they select a character, but converting
to this sort of system is way more work than would be worth it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3758 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne