Status Report: one.world (02/27/2001)
We have a 80% - 90% functional system going thus far.
(Daniel)We are basically down to a couple of things,
integrating stuff together via discovery. Once we are done with
that - we're done. Of course this leaves out some stuff like
checkpointing, migration and intricate error handling. Plus my
code is UGLY. Another day or two.
- Broke user repository/registry up into two seperate components,
Inbox and Authentication (Daniel)
- Authentication is usuable - rough edges still exist (Daniel)
- Inbox is usuable - rough edges still exist (Daniel)
- Wrote GUI component to communicate with Authentication -
still broken (Swing,AWT???) (Daniel)
- Refactored stuff as usual (Daniel)
- Even more debugging - wasted 2 days on dumb
- Researched discovery (Daniel, Albert)
- Integrated Components - Filter & Inbox are communicating,
Monitor and Authentication are communicating (Daniel,
- Filter running. Router close behind. (Albert)
- Code done to Daniel's style (RemoteMainComponenets, Whoami's etc) (Albert)
- Event Dispatching system generalized a bit (Albert)
This is the priority for the rest of the week. Higher priority
items need to get done first.
- Integrate and test existing code (Wednesday)
- Finish Pop3 interface to clients using Ian's work
- PYSCH101 Midterm on Friday, CSE461 HW Due Friday/Monday
- Start documenting (Sunday, Daniel)
- Personal Code Freeze (Saturday Night, Daniel)
- Finish SMTP interface to mail servers. (Nice but not
necessary, do REP directly with the Inbox)
- Finish Router (Albert)
- Get some service components up (Albert)
Deliverables for next tuesday
- Integrated and Working System (Daniel)
- Draft of documentation (Daniel)
- Router done with (Albert)
- Service Component interface as well as componenets themselves up (Albert)
- Looked at Discovery: 2hrs
- Switched to one.world 0.4: 2hrs
- Debugging: 10hrs
- Debugging Swing/AWT - still broken: 10hrs
- Authentication: 10hrs
- AuthInfo - still broken (see Swing/AWT): 10hrs
- Inbox: 10hrs
- Integrated Authentication and Monitor: 6hrs
- Got Inbox and Filter communicating with Albert:
- Refactoring: 2hrs
- Finishing Filter: 8hrs
- Playing with Discovery: 1hrs
- Router Implementation: 4hrs
- Event Dispatching System: 4hrs
- Integration with Daniel: 3hrs
As usual comments for me to write on later on, but may be
helpful to whomever right now.
Alright, maybe spending last week refactoring the system was
not such a good idea. We are definitely behind schedule. End of
quarter madness as usual ...
[rant mode on]
Swing threading stuff is brain dead. Or at least I'm brain
dead. When you click a button, why does it cause an exception
if you do something like request_.handle(blah);
[rant mode off]
Problem: I realize it has something to do with the way Swing
does it's threading. I just don't have the time to fix it
Solution: Bootstrap authentication by reading a properties
file that contains the relevant information i.e like my
password. Not the ideal solution since the properties file is
in clear text. It will work for now.
There is a nice poster outside about "MultiJava: Modular Open
Classes and Symmetric Multiple Dispatch in Java" by Todd
Millstein and Craig Chambers. I have not had the time to read it
fully but it seems to have some ideas on a better way to do
the event dispatching we were discussing. I'll have to go and
read that poster more thoroughly when there is more time.
Albert gave a nice link this week on interface
design. I've violated all the design nonsense they
talked about. Some of them would actually help.
Oh well, at least I can still thump people on
the head with my GoF book.
Major misdesign by me. I did'nt realize what
PendingInputRequest was until it was too late. It would
definitely help when communicating remotely i.e keeping track
of what came back. I should not have gone off and written my
own stuff to do something like that. The problem was that we
designed our own types (subclassed from one.world.util.TypedEvent)
for passing around in the system. If we had more intelligence,
subclassing it from InputRequest would have been a smarter
idea. Of course I could complain that PendingInputRequest
could have been written more generally.
OutputRequest(EventHandler source, Object closure, Tuple
tuple, EventHandler txn)
What is txn used for? It seems vaguely useful.
I begin to realize why transactions and queries on nested
fields are nice to have. Trying to confirm that stuff got done
on a remote system is harder than it seems. I did'nt feel like
implement 2-phase commit this week.
Smart sender, dumb receiver is a nice design principle.
This may already be in the system (or it may be not). This
would have been nice to have. Let's say you send a remote
event to a remote system. We want to check that a reply has
come back for that remote event. There are a couple of places
that this can be done (1)set a timer event to tell you to
check at regular intervals (2)whilst handling another event
(say the response comes back) do the necessary work.
I feel (2) does not work as well since it assumes that the
responses will come back to a certain degree plus it may
complicate the code in that area. (1) is a better
solution but you don't necessarily want to handle all the
timing code to check how long a message has been sent (think
scheduling algorithm in OS). A nice solution is to put an
explicit timer on every message you send out. When the timer
expires, you are flagged and you handle it then. I believe you
can do it right now, its just messy.
Lots of random thoughts this week
- Daniel's class heirchy is *really* nice
- Looking at Daniel's event handling hierarchy, I think we're both
edging towards the same idea. The idea is that the handlers should
not have all hte event handing code in them. That's gross. Though
it's a bit unclear still, I think the basic idea is to split
according to type within the handler and then throw the event to a
demultiplexer which will contain the actual handling code. Daniel
created the "demux" class to this end. I, still prefering the
less static method decided after looking at his to make a "dispatch"
interface. I think we're converging here on what we want to do.
I also think this idea is much more clean. So you split on event
type in the handler, and then you pass it off to a dispatcher/demux
class which probably should be organized by semantec groupings like
"Input Output," "Error Handling" "Control" or something.
The initial startup and shutdown code always require roughly the
same handling. Following the demuxing method above, I think there's
another split that could *greatly* simplify things, however, I am
having troubles coming to a good division here. Most things have
some sort of "init" function. In one.world, you've got at least
3: Constructor, init, and then what you call during the ACTIVATED
event. I really don't like that.
It makes me wonder if there's a better factoring. Thus far, I've
come up with trying to factor according to 3 lines -- which is still
gross and I think it's the wrong factoring, though I don't have
experience thus far to figure it out. i'm spliting between:
Serializable startup/shutdown, non-serializable startup/shutdown,
running startup/shutdown. This does not seem ideal at all. However,
if I can find a decent split, then the service component interface
could ostensibly just be inherit, create any init for instantiation,
run. Not sure yet. Still need to work on it more...
Is java.lang.reflect really that slow? If I was querying RTTI, I
could see it taking forever, but after getting a reference to a method,
invoking it should be failry fast shouldn't it? Assuming that, I think
the dynamic event dispatching method should be really fast...
- pico rules
- It might be nice if one could split tuples according to their
semantec meaning. What I mean is that Simple Input/Ouput events
are more similar than EnvironmentEvents, but they're all typed events.
Then again, this is a very fuzzy area and there isn't likely to be any
good way to split this in a general sense (other than making a table
or something), but on can always dream (about Go boards and monkeys
Last modified: Tue Feb 27 16:06:28 PST 2001