Monday, December 06, 2004

Danny's principle

It seems to be a common feature of naieve propoals for handling spam that they would cause an increase in load on other parts of the email system when working sucessfully.

I believe that the only parts of the system which should experience an increase are those parts directly associated with identifying and removing the messages from the system, be these filters or white/black lists or DNS (for SPF etc) or so on.

Increased resource consumption should be contained in only those parts of the system involved, and ideally to the extent that a direct correlation between the resource requirements and the volume of unwanted messages exists, allowing capacity to be estimated and provisioned acurately.

In fact I'm so suprised that this isn't recognised as a universal truth that I've written Danny's principle, in three parts;

  • "I/ In any messaging system any components involved with identifying and removing unwanted messages should, when operating sucessully, create conditions in which no other parts of the system experience an increase in resource consumption as a direct consequence, and should tend to reduce consumption in some components as a consequence of removing unwanted messages."
  • "II/ Any components identifying and removing unwanted messages from the system should reduce their resource consumption as the number of unwanted messages they are challenged with reduces"
  • "III/ Resource requirements for components identifying and removing unwanted messages from the system should be designed to be predictable and based upon measureable attributes of the traffic."

This is an important practical consideration for the uptake of any technology.
Ideally resource consumption will be influenced only by the most basic attributes, such as message volume, but where it is influenced by more sophisticated attributes, such as message content or routing, it must be possible to predict requirements after analysis of current or comparable traffic.

Tuesday, November 09, 2004

UK oracle users conflab

HJust back, well back last week, from the UKOUG conference.
A quick summary of the cool stuff has to include BPEL at the top of the list, check that out, for orchestrating and choreographing web services. It works like a dream with Axis. Runtimes available for OC4J and JBOSS and another container which I forget right now.

More importantly is the tool though, and the eclipse visual BPEL plugin is a major cool thing, its pretty and it works. check it out.

On that note the Jdeveloper10, and I'm not a Jdeveloper fan I prefer to stick with Eclipse, is looking pretty smart with support for struts pageflow diagrams (diagramming struts-config.xml, how much use would that have been 18 months ago) some really useful looking web-services-security wizards, not available yet but we got a sneak preview and they look like they'd help anyone get to grips with WSS in quick time, and model driven development with synchronised round trip through several diagram stages to code and back again.
I'm not going to go overboard with praise here, but there is some serious *potential* for this to become a top class RAD tool for J2EE, if Oracle don't cut any corners in their support for open standards and synchronised code<->diagram.

We also saw ADF, which I'm a bit more suspect about, I don't believe that Struts is a good choice for RAD, and I speak from experience, particularly because it is not possible to get much encapsulation, reuse and component architecture. Also Oracle tie you in to an Oracle BaseAction reducing the portability of the developed apps. I'd've been happier if we could have seen Tapestry (ok probably not realistic) or even seen the JSF support, which was talked about but not demoed, least not that I saw.

OTOH ADF, BPEL and Jdeveloper together look like a fine path for Oracle to allow people with proprietery skills to make an easy transition to developing oracle apps using J2EE.

Over all it was nice to see that they are embracing open standards, even if they still have a load of work to do to satisfy a grumpy old purist like me..!

Look out for me at the next one ...

Sunday, October 31, 2004

I think this email should become a blog post

Does it really work?

Friday, October 29, 2004

killerbees: Hey I got a blog

killerbees: Hey I got a blog

Hey I got a blog

Morning all.
I now have a blog. I imagine it'll take a while for me to work out what I want to say here.
But I think this'll do for now.

I know nothing, I'm not a fortune teller, and you'd be insane to think that I am. This disclaimer was cribbed from an email footer I once received. It is so ridiculous I had to have it for myself.

Statements in this blog that are not purely historical are forward-looking statements including, without limitation, statements regarding my expectations, objectives, anticipations, plans, hopes, beliefs, intentions or strategies regarding the future. Factors that could cause actual results to differ materially from the forward looking statements include risks and uncertainties such as any unforeseen event or any unforeseen system failures, and other risks. It is important to note that actual outcomes could differ materially from those in such forward-looking statements.

Danny Angus Copyright © 2006-2013 (OMG that's seven years of this nonsense)