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.

Last Week

This Week

This is the priority for the rest of the week. Higher priority items need to get done first.

Daniel

  1. Integrate and test existing code (Wednesday)
  2. Finish Pop3 interface to clients using Ian's work (Saturday)
  3. PYSCH101 Midterm on Friday, CSE461 HW Due Friday/Monday
  4. Start documenting (Sunday, Daniel)
  5. Personal Code Freeze (Saturday Night, Daniel)
  6. Finish SMTP interface to mail servers. (Nice but not necessary, do REP directly with the Inbox)

Albert

  1. Finish Router (Albert)
  2. Get some service components up (Albert)

Deliverables for next tuesday

  1. Integrated and Working System (Daniel)
  2. Draft of documentation (Daniel)
  3. Router done with (Albert)
  4. Service Component interface as well as componenets themselves up (Albert)

Time spent

Daniel

Albert

Comments

Daniel

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 ...

  1. [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 right now.
    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.
  2. 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.
  3. 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.
  4. 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.
  5. OutputRequest(EventHandler source, Object closure, Tuple tuple, EventHandler txn) What is txn used for? It seems vaguely useful.
  6. 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.
  7. Smart sender, dumb receiver is a nice design principle.
  8. 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.

Albert

Lots of random thoughts this week

  1. Daniel's class heirchy is *really* nice
  2. 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.
  3. 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...

  4. 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...
  5. pico rules
  6. 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 nonetheless).

Daniel Cheah
Last modified: Tue Feb 27 16:06:28 PST 2001