need the two argument versions as well, but I'll wait and see.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4378 542714f4-19e9-0310-aa3c-eee0fc999fb1
unmarshalled into an ArrayList on the receiver. Along the way, I improved
support for generic types as arguments to invocation services (which required
one unfortunate "sweeping" warning suppression, but since this is in generated
code, I think we can be sure it won't be doing anything untoward).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4375 542714f4-19e9-0310-aa3c-eee0fc999fb1
around of the interface (I wanted to automatically call getStreamerClass() for
the caller but that turns out not to be possible when unstreaming so fuck it).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4373 542714f4-19e9-0310-aa3c-eee0fc999fb1
are now correct, but unfortunately a little more complicated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4371 542714f4-19e9-0310-aa3c-eee0fc999fb1
type, but we don't really want to pollute our class <-> id mapping with a bunch
of extra fiddly enum classes, so we stream all enums as instances of their
declared type and let Enum.valueOf() map back to the custom derived type when
it creates an instance during deserialization.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4370 542714f4-19e9-0310-aa3c-eee0fc999fb1
value to avoid future compatibility problems if someone saves an object to a
database and then later adds a new enum anywhere but at the end of the list,
thereby changing the ordinals.
If you want maximal network efficiency, don't use enums. For most of what we'll
do with them, it doesn't merit having the future incompatibility hitch of
sending the ordinal.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4369 542714f4-19e9-0310-aa3c-eee0fc999fb1
ObjectInputStream works in conjunction with a ObjectOutputStream on the
other end. The ObjectOutputStream will always assign class codes starting
at 1 and increasing sequentially from there, so we can look up a class
by index rather than hashing.
Uses less memory and is faster.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4365 542714f4-19e9-0310-aa3c-eee0fc999fb1
process and keep that information around in case the server ever wants to know.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4356 542714f4-19e9-0310-aa3c-eee0fc999fb1
This is actually kind of sketchy, because the resolver can't depend on it
because there are methods to resolve a client object without having an
authenticated connection.
For now, I'll leave this in.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4350 542714f4-19e9-0310-aa3c-eee0fc999fb1
looking for something assignable from Object (rather than the other
way around) when the argument was null.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4346 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
otherwise we'll just get the name. I'm killing StringUtil.getMessage().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4304 542714f4-19e9-0310-aa3c-eee0fc999fb1
may already be the case that the normalize() method returned the same
String, but if not, ensure that we're only holding on to one of those Strings.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4297 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
We need to set up the preference interval (but not start it) before we try to open the connection. Otherwise, we won't have it around if we get a shutdown call during that opening (which can and does happen).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4274 542714f4-19e9-0310-aa3c-eee0fc999fb1
where we don't think it ever will.
Instead of returning null, or the exception, always throw a runtime
with just the CloneNotSupportedException as the argument, as this will
contain the most information and will preserve the stack trace.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4264 542714f4-19e9-0310-aa3c-eee0fc999fb1
I was getting an IllegalArgumentException and the message was "null",
so this will at least log the name of the exception.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4263 542714f4-19e9-0310-aa3c-eee0fc999fb1
inner bits are all clear and ready to try logging on to a new server. We
specifically wait to call clientLogonFailed() until after everything is
cleared, but I don't want to change the behavior of clientDidLogoff() for fear
that any one of the zillion directors depends on something being around during
that call.
Instead I added another callback clientDidClear() that is called when a
successful session is fulled cleared out (basically when we're not calling
clientLogonFailed()) so that entities that are waiting for a logoff to finish
so that they can logon somewhere else have a clean way of doing so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4255 542714f4-19e9-0310-aa3c-eee0fc999fb1
like to change the ordering for ChatMessage and its other derivations (the
bundle should precede the message) but that's more dangerous as the constructor
signature would not change.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4253 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
we can't rely on building a new client info at session end time because the
client's ClientObject will have been destroyed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4250 542714f4-19e9-0310-aa3c-eee0fc999fb1
decrement the reference count of the client object as it is normally
incremented for every resolution listener.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4248 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne