| March 2002 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 | ||||||
| Feb Apr | ||||||
This site is no longer maintained.
My current weblog.
Friday, March 15, 2002Last night I received an email Justin, the person behind the Wasabii spec. He pointed out that I had been looking at the wrong spec, that his spec is an evolution on that.
Mea culpa. The proper Wasabii spec addresses my concern that defined object methods are too inflexible. Wasaboo makes use of structs to handle undefined metadata. Wasabii also adds the (optional) concept of sessions, in an ASP-like way, which would cut down on the number of plain-text passwords being passed around. Unfortunately it does not address how sessions will be expired.
Neither does it add any sort of password security. SSL may provide a sufficient level of protection, but due to it's complexity it may not be implemented by the majority of client and server apps. This is a glaring hole that has been completely ignored. Someone needs to step up and address this. "Reasonably Secure" without excessive complexity. It wouldn't need to stand up to Bruce Schneier, just slow him down.
Generic Object Access
Last night I began working on my spec for generic object access. The intent is that this spec should be integrated into a fuller CMS API, such as Wasabii. It would allow a CMS to provide access to objects that fall outside the scope of the pre-defined object types, in a standard way. Client applications, if they choose to, can operate on implementation-specific objects without requiring domain knowledge.
I'm starting to suspect that this spec may wind up being too complex for "light" clients and servers. There may also be overlap with WSDL, I need to look into that...
Argh. Finally got around to installing Navigator 4.08 (the last stand-alone release), Communicator 4.79, and Mozilla 0.99. Each of them have significant rendering problems.
Navigator / Communicator
Not even sure what level of CSS support these are supposed to have. Don't appear to support the box model at all. Both dork the graphic border on the table.
Mozilla
Initially loads with the default stylesheet. Clicking the links on the bottom to change stylesheets does work. A while line appears where the coffee mug graphics come together, and there is an oddity with the first <hr> in the table.
Suppose that 4.x browsers aren't really worth caring about at this point. The Mozilla stylesheet issue is a problem tho. I'll need to build a few test-cases to determine why my selection script is failing. Then I guess I'll need to check it against Opera and a Macintosh.
<sigh>
The minor visual problems don't bother me at all. They are the result of trying to shoe-horn a table-based layout, which uses several table tricks, into a CSS Box layout. When I get around to creating my own layout those problems will go away.
Achieved my first milestone in MOB this morning, I created a very simple test program that makes an XML-RPC call to Radio. It works.
The down side is that I'm encountering too many limitations with Embedded Visual Basic. There is no capability for class modules, nor creating ActiveX/COM components. There is no native Collection or Dictionary object.
Hopefully I will have Visual Studio .NET in my hands tomorrow. The .NET Compact Framework levels the playing field for VB Pocket PC apps. Hopefully the runtime footprint is acceptable on a 32MB PPC 2002 device.
I've passed my changes on to Richard. I've asked him to integrate them back into his development environment. It's a way of double-checking that I didn't FUBAR something in a manner not noticeable on my own machine.
After my other projects have moved farther along I may revisit the add-in. It could use a feature for editing posts. FrontPage provides a great user experience for "writing the web", bloggerCOM and the FP add-in bring that experience to blogging.
