Leaving RootDObjectManager's declaration of newInterval() alone, because it contains docs that are specific to its implementation.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6474 542714f4-19e9-0310-aa3c-eee0fc999fb1
(as we sometimes do when we transfer a player between peers in Project X).
Technically we probably shouldn't be streaming the marshallers in that case,
but doing this (and clearing the marshaller on the receiving end) is simpler
than clearing, streaming, and restoring; or settings things up so that the
marshaller is specifically excluded from streaming in transfers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6467 542714f4-19e9-0310-aa3c-eee0fc999fb1
the default comparison methods in a symmetric way (so that it doesn't matter
which of the two objects' equals/compareTo methods was called).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6465 542714f4-19e9-0310-aa3c-eee0fc999fb1
match DSets and setting attributes. With the old behvaior, if a client subscribed to a DObject and
modified an OidList on it in a single pass, it could miss the modification. The DObject is
serialized immediately when the server gets the subscription request, but events aren't sent for
that subscription till it's processed the next time the omgr queue comes round.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6420 542714f4-19e9-0310-aa3c-eee0fc999fb1
well in standalone mode. We need a way to install a director on registration.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6413 542714f4-19e9-0310-aa3c-eee0fc999fb1
(not by its superclasses), we need to rise through its superclasses as well
in order to find the provider interface.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6411 542714f4-19e9-0310-aa3c-eee0fc999fb1
ProjectXZoneRegistry extends a class that is a ZoneProvider...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6409 542714f4-19e9-0310-aa3c-eee0fc999fb1
use JVM generated proxies, nix marshaller/dispatcher."
The idea was to use Proxy.newProxyInstance to magically create (at runtime)
proxies for FooService interfaces instead of generating a bunch of boilerplate
code. I figured something similar could be done for FooDispatcher on the server
side.
However, we also generate C++ and ActionScript marshallers, and those aren't
ever going away (AS might support some sort of dynamic magic to do what we
need, but C++ sure don't). So I decided to leave the marshaller side of things
as is.
I did revamp the dispatcher side of things to eliminate the need for
FooDispatcher on the server. This turned out not to even require the use of
something so magical as java.lang.reflect.Proxy, because in this case we're
just reading in method ids over the network (and arguments), and calling the
appropriate method. Such mundane activities are easily accomplished with the
regular reflection API.
The existing dispatcher stuff still works as well, of course, and though the
conversion from the old style to the new style is pretty simple:
< invmgr.registerDispatcher(new FooDispatcher(fooprov))
> invmgr.registerProvider(fooprov, FooMarshaller.class)
there's no burning need to convert things over. Fortunately, there's no
(compatibility) impact on client projects to converting Narya and Vilya, so
I'll be doing that shortly. There will be a miniscule performance impact, but I
think the cost of a single reflective method call, given that all of its
arguments were read and unmarshalled from the network, will be a good distance
south of immaterial.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6403 542714f4-19e9-0310-aa3c-eee0fc999fb1
is a bad idea and will lead to pain. Nixed the one place where toArray was used
(which was a serous pig's breakfast itself).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6402 542714f4-19e9-0310-aa3c-eee0fc999fb1
Tom Conkling