Files
narya/docs/presents/notes.txt
T
Michael Bayne ae114ceae2 Notes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@541 542714f4-19e9-0310-aa3c-eee0fc999fb1
2001-10-24 00:40:25 +00:00

95 lines
3.3 KiB
Plaintext

Presents Notes -*- outline -*-
* TODO
Pass cause back to client somehow via FailureResponse in Client.requestFailed
clientWillLogff becomes clientMayLogoff?
Look into nbio waking up all sockets when any data comes in.
(maybe) Allow piggybacking of object subscription onto service defined
responses (like moveTo request).
(maybe) Allow better server side control of subscription management (to
ensure that clients don't remain subscribed to objects they should no
longer be susbcribed to; like scenes they've departed from).
Sort out support for server-side modifiable only fields to DObject.
Create a CompoundEvent that allows packaging up of multiple events to be
dispatched in unison. Build dobj source generator and have it add versions
of all update methods that take a compound event to which to append the
event rather than dispatching them directly.
Maybe make AuthResponseData a Streamable instead of a DObject.
Have the LocationRegistry register the LocationProvider rather than doing
it via a config file. Perhaps lose the config file element altogether.
Think about Subscriber business and whether or not DObject needs a list of
subscribers or if there's a better way to handle removedLastSubscriber()
on the client side and not taint the server side with all dat crap.
* Server-side event concentrator
The client objects will not subscribe directly, but will subscribe through
the concentrator so that, at least, it can create a single
ForwardEventNotification for each Event being dispatched to a group of
clients. Optimally, it would be able to flatten that notification as well
and the byte array can be written to the socket of each of the individual
clients rather than creating a separate byte array for each client. This
will require a special "flattened notification" that can be inserted into
the queue to preserve message ordering but then is simply sent rather than
flattened and sent.
* Marshaller
Consider how the dobject marshaller deals with classes loaded and reloaded
using flushable classloaders.
Also consider whether access to the marshaller cache needs to be
synchronized.
* Check into "connection closed by peer" thread exiting on client
* TypedObjectFactory
Maybe modify so that types are assigned automatically even if everything
has to be registered in a single place, since it pretty much does anyway.
* Client network mgmt
Client perform all network ops on own thread, will call back to main code
through Observer interface to notify of state changes in the
authentication process/connectedness:
public interface ClientObserver
{
public void didConnect ();
public void connectionFailed ();
public void didLogon ();
public void logonFailed ();
public void didDisconnect ();
public void didLogoff ();
}
* DObject class generation
Distributed objects are defined like a class with a set of public data
members which is then converted into an actual class with get/set methods
for each member.
public dclass GameObject
{
public int[] players;
public String description;
}
becomes
public class GameObject extends DObject
{
public void setPlayers (int[] players);
public void setPlayersAt (int index, int value);
public int[] getPlayers ();
public int getPlayersAt (int index);
public void setDescription (String description);
public String getDescription ();
}