use in non-sandboxed environments). Unfortunately we have to do this for all
Streamable classes, not just the ones that have protected/private members
because we need to be able to call super.readObject() and have that exist even
if our superclass contains only public members.
Doing magic streaming with combinations of classes that do and don't have
readObject() would start to get extremely complicated, particularly if the base
class had readObject() an intermediate class had none, then a later class had
one again. Madness. Doing things with compiled methods will be faster anyway...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4686 542714f4-19e9-0310-aa3c-eee0fc999fb1
clientSessionDidEnd() which is called on the dobjmgr thread directly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4680 542714f4-19e9-0310-aa3c-eee0fc999fb1
the controller has located the appropriate function.
- If the arg for a command or callback is an array, assume those are
the parameters for the function. If you desire passing a single array
argument, you've got to wrap it in another array, otherwise single
args will be automatically wrapped for you.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4676 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
fake Entry implementation. This also avoids breakage if a DSet entry's key
itself implements DSet.Entry (which just happened for the first time in Narya
history).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4673 542714f4-19e9-0310-aa3c-eee0fc999fb1
- handle // @Override // blah style comments
- deal with fields that are assigned to anonymous inner classes (actually
anything with braces, which would also include array literals).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4667 542714f4-19e9-0310-aa3c-eee0fc999fb1
them to the appropriate ChatDisplay when we're doing chat in IM-style
individual windows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4663 542714f4-19e9-0310-aa3c-eee0fc999fb1
something funny is happening with spurious objects dispatched across servers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4657 542714f4-19e9-0310-aa3c-eee0fc999fb1
will not name, was trying to allow certain authentications to proceed directly
on the authenticator thread instead of making a round trip through the
invoker. This resulted in those authentications trying to post their results
from the authenticator thread, which is bad because all downstream messages
should be posted from the distributed object thread.
The only authentications that would "benefit" from this optimization were peer
authentications of which there would be extremely few (currently one in our
largest installation) compared to the hundreds of thousands of normal
authentications, which have to make the invoker thread round trip as a matter
of course.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4655 542714f4-19e9-0310-aa3c-eee0fc999fb1
process an authentication request if it is asked to do so before it has an
invoker (meaning the server is not yet initialized).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4654 542714f4-19e9-0310-aa3c-eee0fc999fb1
looks like it should be running on the dobjmgr thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4653 542714f4-19e9-0310-aa3c-eee0fc999fb1
except that messages will never leave the server. If generated on a client,
they'll go to the server and be processed like a normal event there
(event handlers will be called) but the event will not leave the server and
be sent to subscribing clients.
Changed the ManagerCaller used by PlaceObjects to use ServerMessageEvents.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4648 542714f4-19e9-0310-aa3c-eee0fc999fb1
if it is called from any thread except the distributed object dispatch thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4647 542714f4-19e9-0310-aa3c-eee0fc999fb1
until after the INIT stage. I don't think this particularly matters for
parameters, since if the URL is unknown it almost certainly means that we
will not need to do the custom parameter loading anyway, but let's just
make sure.
This also knocks a "known issue" off my list, and opens up the possibility
of remixed items loading content packs from a relative URL.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4646 542714f4-19e9-0310-aa3c-eee0fc999fb1
in case we freak out in the middle of writing a message.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4645 542714f4-19e9-0310-aa3c-eee0fc999fb1
fork in the proceedings, pass the partially initialized request on to the
authenticator who will either get a version of 0 or an out of date version and
reject them properly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4640 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne