objects (DSet, arrays) in a DEvent (which should not change as a result of
other events being applied) and those in the object itself (which do
change and evolve as events are applied to the object).
This is important both because the DEvent is passed on to another thread
for delivery to remote clients, thus changes to the values in the event
could take place before they were serialized and sent over the network,
and because compound events are applied to an object before they are sent
to the other thread for delivery and thus, for example, setting a DSet and
then adding a few entries to it in a compound event would result in the
DEvent copy of the DSet becoming corrupted.
Two problems remain (note, neither of these are new, the one issue
introduced when I rewrote the DObject stuff is fixed by these checkins):
1. Object subscription requests are supposed to deliver a snapshot of the
object at the point in the event stream at which the subscription
request was processed, but presently we pass only a reference to the
object off to the networking thread which means that before the object
is serialized and sent to clients, subsequent events could be applied
to it and then those events would be sent to the client as well
resulting in funny business (probably nothing more than duplicate DSet
entry warnings, but imagination and Chapter 17 tell us that worse
things could happen).
2. The use of Streamable instances could result in badness. If a field in
a Streamable is modified and the whole Streamable set() back into the
object to broadcast the update, then further changes were made to the
Streamable before the attribute change event was serialized and sent
over the network, the second modifications would be reflected in the
event triggered by the first modifications.
The first problem may be solvable (albeit inefficiently) by serializing
the DObject on the event dispatcher thread and sending that serialized
copy off to the network thread for delivery to the client. It would be
much less efficient as we would be unable to make use of the client's
already "primed" ObjectOutputStream which may have already mapped many of
the classes in the object to two byte codes, but object subscription is
fairly uncommon compared to delivery of events, so inefficiency might not
be a big problem in this case.
The second problem might be solved by requiring that all Streamable
implementations implement clone() and then cloning any Streamable
attribute just as we do an array or DSet during an attribute, array
element or DSet entry change. This would be a more significant performance
hit as well as require a review of all of our Streamable classes (to
determine if they need a custom clone() implementation), and it has up to
now not actually manifested as a problem.
In any case I'm not going to tackle either of these remedies at the moment
because I'm on vacation, dammit.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3294 542714f4-19e9-0310-aa3c-eee0fc999fb1
because it plays games in a special place rather than actually moving the
player into the game room which naturally registers the place object as a
chat source. Fortunately, we can implement the necessary hackery to
support Yohoho in a reasonably generic manner.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3291 542714f4-19e9-0310-aa3c-eee0fc999fb1
accomplish our "previous value" support in the distributed object system
without using reflection and could also avoid using reflection in the case
where we have already applied the event on the server (which is generally
the case on the server).
Rather than hacking up the gendobj script, I took this opportunity also to
rewrite the DObject generation script as an Ant task and in doing so,
implemented another recent idea which is that we can just augment the
FooObject.java file instead of having a separate .dobj and .java file.
You'd think it was spring there's so much cleaning going on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3284 542714f4-19e9-0310-aa3c-eee0fc999fb1
There is no more SafeInterval, instead Intervals can be constructed with a RunQueue to use for expiring.
PresentsDObjectMgr implements RunQueue.
Client has a getRunQueue() method to get the client side RunQueue.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3283 542714f4-19e9-0310-aa3c-eee0fc999fb1
custom keys to include a 'global' section, I've just re-added the P key
in a hard-coded manner. If the P key is pressed, the puzzle isn't already
paused, and the user has not redefined P to perform some other command in
the puzzle, it will pause.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3279 542714f4-19e9-0310-aa3c-eee0fc999fb1
Will this change be as ill received as removing "P" from chat? Who knows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3278 542714f4-19e9-0310-aa3c-eee0fc999fb1
wacky notion from Yohoho that shouldn't really be in parlor in the first
place.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3276 542714f4-19e9-0310-aa3c-eee0fc999fb1
Java's magical security system to do the right thing (or so I think).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3274 542714f4-19e9-0310-aa3c-eee0fc999fb1
it's unlikely that the rabbit hole will surprise us with further depth.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3269 542714f4-19e9-0310-aa3c-eee0fc999fb1
classloader to use when unserializing objects off the network. Also fixed
the way custom classloaders were used as Class.forName(class, true,
loader) seems to be the proper way to go to have caching work and whatnot.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3268 542714f4-19e9-0310-aa3c-eee0fc999fb1
This fixes the bug where there was no pause message in carpentry.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3264 542714f4-19e9-0310-aa3c-eee0fc999fb1
creates a traditional lobby->room server with narya, and instead allow
a broadcast object to be registered with the ChatProvider to which all
broadcasts will be sent.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3261 542714f4-19e9-0310-aa3c-eee0fc999fb1
loader approach can't work. But it's useful to set a proper example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3256 542714f4-19e9-0310-aa3c-eee0fc999fb1
realize I will probably have to change it further.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3252 542714f4-19e9-0310-aa3c-eee0fc999fb1
effectively be accomplished with a combination of ResultListenerList and
ResultAdapter.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3250 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne