the LogoffRequest being received by the server which resulted in the server
closing its end of the socket which resulted in the reader being woken up to
hear that its socket was closed and then it exited. We'll just have it exit
immediately. It's possible that messages in transit to the reader that would
have been read prior to full shutdown will now be dropped instead of delivered,
but the client has already requested to logoff, so they can't really care about
additional messages coming from the server.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4960 542714f4-19e9-0310-aa3c-eee0fc999fb1
our generated services & whatnot, so that's a much deeper rabbit hole than I was
thinking when I just did that one big, so I'm going to leave that well enough alone
for now instead of half-assing it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4949 542714f4-19e9-0310-aa3c-eee0fc999fb1
like this, we can think about where the interface would be useful.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4910 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
servers for execution. The class in question must exist on the remote server
but all of our servers are all always running the same code, so this follows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4882 542714f4-19e9-0310-aa3c-eee0fc999fb1
than trying to go to our previous place. If we're no longer in a place (like we
switched servers to get where we're going), then we'll try to go back to our
previous place.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4875 542714f4-19e9-0310-aa3c-eee0fc999fb1
outstanding know that their subscription request failed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4873 542714f4-19e9-0310-aa3c-eee0fc999fb1
politely complain that they're talking a lot but not disconnect them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4871 542714f4-19e9-0310-aa3c-eee0fc999fb1
(e.g toString(StringBuffer)) we use the properly renamed version
(e.g. toStringBuffer(StringBuffer)) when generating our ActionScript.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4870 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
can't ever be false. (And just above, we've already confirmed that channel != null, so this
check wasn't falling back to protecting us from that)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4867 542714f4-19e9-0310-aa3c-eee0fc999fb1
DObject. There will never be multiple instances with the same oid that
represent "equal" objects and it's possible that in certain (controlled and
limited) cirumstances, objects with different object managers might have the
same oid even though they are different objects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4853 542714f4-19e9-0310-aa3c-eee0fc999fb1
superclass chain. Other such annotation "inheritance" is needed for methods,
but that I'll do later.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4840 542714f4-19e9-0310-aa3c-eee0fc999fb1
Mike Thomas