Subj : Re: Change Patterns (was: Polymorphism sucks) To : comp.programming,comp.object From : rem642b Date : Wed Aug 10 2005 04:55 pm > From: Programmer Dude > what possible value can there be to putting XML message data in > transit into a database? Assuming a database is readily available where you're running this software, I see the following advantage: A database is a really stable place to store data. If it's common that a message is ready to be sent but the receiver is busy and can't accept it right away, there's a chance the message might get lost if the sending process happens to crash before being able to hand off the message. The longer the average time a message must wait, the greater chance a crash will occur. But if it's immediately put into a database, it'll be safe there no matter how long, even though a system restart. Furthermore, having everybody talk to a single database service is less programming than having everybody talk to everybody else individually. If every program is already talking to the database at least once, then it's no additional interface code at all, only high-level application code, that is needed. > I probably would NOT use OO for a device driver, depending on how > low-level it was. In many cases, I drop right down to raw assembly, > at least for bits of it (pun very definately intended!). If SysLisp were available, I'd prefer that. But normally that wouldn't be available, so I'd agree on assembly language as the best choice. > class HTMLOutput extends Output Before you can start to design the code, you have to abstract out the lowest common denominator of features you plan to support. For a recent class project I needed to do something like that in a preliminary form. The goal was to make a common interface that would work in all of these modes: OUTPUT/PROMPT INPUT/CONTROL javax.swing repaint mouse&keyboard events HTML forms uuencoded form contents VT100 display keyboard text, and emacs/lynx/VT100-style cursor motions standard output standard input to select form-field to edit, or to submit The conceptual base for the common protocol was that display elements could be flowed horizontally with automatic line breaks, or stacked vertically one per line, to form larger units, and primitive (leaf) components could be plain text or any of the various form components (text fields, text areas, buttons, checkboxes, radio buttons, etc.), with a default vertical stacking for any separate toplevel objects successively sent to through the stream. Note that any feature of one UI that isn't easily emulatable in all the others, such as stylesheets in HTML, or realtime dynamic actions such as possible with JavaScript or javax.swing, or haphazard explicit x,y layout of components in javax.swing, would not be supported in this system. All actions would be constrained by the form-submit client/server cycle, so that the only actions possible within a single form-fillout part of the cycle would be simple single-component actions such as editing text within a text field or text area, clicking checkboxes etc. on/off, and scrolling the whole 'page' if it didn't entirely fit on-screen. (Yes I'm serious about making server-side software available both locally and remotely via all the usual UIs.) .