subclasses provide PresentsServer "services" we'll just have no PresentsServer
services. All services will be provided by components and the server will
disappear in a puff of inversion of control.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5155 542714f4-19e9-0310-aa3c-eee0fc999fb1
is only ever used by the PresentsServer. Also determined that we need to
explicitly let Guice know that CrowdServer provides the PresentsServer
"interface" and so on down the line.
I also think that each concrete class needs to be marked as @Singleton though I
need to confirm that. Based on how annotations work, that's how it would be
easiest to implement, so we'll assume they're not doing extra work on the
backend to make our life easier.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5154 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
easily make use of different permission policies in different circumstances
(one can imagine a hypothetical partner who has different access control
requirements, perhaps).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5118 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
completed, or connecting, disconnecting and reconnceting before client object
resolution completes a little more gracefully.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4889 542714f4-19e9-0310-aa3c-eee0fc999fb1
manager prior to it being initialized or started up.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4869 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
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
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
- the ChatProvider is now a proper singleton rather than providing static
methods for everything (it is accessed through CrowdServer.chatprov)
- it can now be extended to create a custom UserMessage for tells (which can
contain avatar information on systems that want to show an avatar on the
receipt of a tell)
- the ChatProvider API was tidied up a bit as some methods had been addded over
time that were not sufficiently general purpose so their callers will be
changed to use the general purpose APIs.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4251 542714f4-19e9-0310-aa3c-eee0fc999fb1
make connections to other servers in the cluster and can exchange events (in a
limited fashion).
This is different than Liz's project wherein servers share an oid space and one
can interchangably work with distributed objects from any server. This package
provides a means by which certain services (by default, presence and chat) can
be communicated between servers to allow communication between players
scattered around a bunch of otherwise independent server instances.
This is less general purpose but also less likely to encourage people to write
code that tightly couples multiple servers and then falls over because it
generates gobs of network traffic as events are flung willy nilly behind the
scenes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4238 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
Michael Bayne