INDEX | ORGANISATION | TIME LINE | PEOPLE | STORY | RESEARCH METHOD | COMMENTARY | FINDINGS | HELP | BOTTOM

Phase II (Sep 93 - Mar 94): Design

' ... we tried to keep it considerably more modular in phase II. ... there's a fixed interface on windows, when you open a window, ... because it might just be made visible, it might already be in memory and then a specific function is called along with the operation is passed who was responsible for opening it. When the window closes again, ... it calls the caller and says I'm done, back to you. This sort of thing.

And that does keep things apart much more whereas in earlier versions you'd have had windows underneath it that would be opened, and they'd suddenly be open and they'd want information and they'd start looking into this one to see what was happening. And then of course somebody else would come along and open it differently and you'd get a bit of code here ... just to check this window isn't open and if it isn't then go and get the data from somewhere else. Mess. The new one is not like that. There are certain windows that can only ever be opened as a child window and they're allowed certain access back to their parents but other than that things are kept separately with this strict "I call it to open it, it calls me back when it's finished." ...

Because the thing was essentially being rebuilt, we were able to sit back before we started and impose a new internal structure on it. That is the main change in the client, is internally it had an initial structure to start with and then everybody was sort of told do it this way and everybody jumped in. ... the idea..the hope was when we did it, that we'd impose this structure and where it didn't really cover a situation, as we went along we'd evolve it. In fact what happened was that we had the structure and where it didn't quite cover it, things have gone their own little way again a bit. But at least we have this central thing.

We applied it not only to that but particularly to database access ... which is now very well structured. Which helps because within the code, say I wanted to make a database access, it's defined in a bit of paper that it will be a loop on the database access and then you'll have a call to a specific object with a function on the loop and if it passes back a SQL retry, which is one of the things it can pass back again, the loop's run again and after that you'll make another call to another function within the same transaction object, there's this object embedded which does all sorts of control for each data..it's one database object, one database permission. You make a call to it which will tell you basically how well it's performed, if it's ok or not, error on that and a) we impose this structure and b) all these errors are handled centrally by this object which does a wealth of things that you would never dream of writing into every script. Where as previously error trapping, was all written into scripts separately and quite differently. This has many advantages, one of which being if the database connection does fail..these are everywhere as I say and this can cope with somebody turning it off. This is our only saviour on days when the thing just hangs, we can just turn it off and turn it back on. ... It does allow the server to go down without the client failing. ... '

X042 page 002.05 (tape 05.2.04) Matt Notes/Tape 14/06/94

Social influence:
Technical influence: Tasks: Software implementation


Recording
Story
Social influence
Technical influence

INDEX | ORGANISATION | TIME LINE | PEOPLE | STORY | RESEARCH METHOD | COMMENTARY | FINDINGS | HELP | TOP

© Clare Tagg 2000