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
instead of a command to CommandEvent. Weirdly, a CommandEvent will never
be generated with the callback way of doing things, but now CommandMenu and
CommandButton will both support the callback syntax.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4629 542714f4-19e9-0310-aa3c-eee0fc999fb1
texty-input components that wish to have the chat system leave their focus
alone.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4626 542714f4-19e9-0310-aa3c-eee0fc999fb1
The way this all works is: when you send a primitive to the server, you
must wrap it up yourself, because there's no way for flash to distinguish
between the integer 3 and the floating point value 3.0.
But when it comes from the server, it's all wrapped up in a very specific
type and we can easily unwrap it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4623 542714f4-19e9-0310-aa3c-eee0fc999fb1
generally be avoided, but nobody's going to override this method and
we're always calling a regular method on the server, not a varargs method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4622 542714f4-19e9-0310-aa3c-eee0fc999fb1
If you pass an array as the varargs argument, it doesn't supply the
varargs like it would in java, instead the whole array becomes the first
argument.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4621 542714f4-19e9-0310-aa3c-eee0fc999fb1
EXACTLY held. I think this is ok because all callers currently pass a single
token at a time, but I have not verified this for every project.
Please verify this for your project!
Added holdsAnyToken() which has the old behavior of returning true if any
bit is on.
I think we should change all the projects' various isSupportPlus() methods
to be just called isSupport() and those will return
holdsAnyToken(SUPPORT | ADMIN | etc);
If you need to check if a user has a single SUPPORT token but is not an
admin, you can do that by hand.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4617 542714f4-19e9-0310-aa3c-eee0fc999fb1
(to match the com.threerings.flex). Let's still put general-purpose flash
stuff here in com.threerings.util.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4613 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne