Tomcat 5 is currently stable enough for me to use, but I think it's use of Jakarta Commons Logging framework is going to cause headaches for webapps using Log4J.  For some reason, Tomcat fails to start if there is an webapp using Log4J.  After spending several hours of fiddling with configuration, I had to stub out all log4j calls from a webapp to get it to work.

XForms 1.0 is finally a W3C Recommendation.  No comment.

There is a lot of discussion going on about ways for user agents (read browsers) can locate site metadata.  People are even arguing about what constitutes a site.  Beside the discussion within W3C TAG, RSS developers are discussing this topic with RSS feed discovery in mind.  Consensus seems to be moving away from using robots.txt style solution which uses fixed-URI.

Tim Berners-Lee wrote back in February:

The architecture of the web is that the space of identifiers on an http web site is owned by the owner of the domain name.  The owner, "publisher",  is free to allocate identifiers and define how they are served.

Any variation from this breaks the web.

Hogwash.

1. Web is just not that brittle.
2. Other solutions are not as easy.
3. User agents should protect themselves from unexpected data.
4. People will not revolt if W3C reserves some range of names if they are reasonably unique.

Simplest solution IMHO is to introduce a special file extension for metadata and a default file name for directory metadata.

For example, if ".w3c" file extension is used for metadata and default file name for directory metadata is empty string, metadata for the resource "/application/foobar.html" can be found in "/application/foobar.w3c" and metadata for the path "/application/" can be found in "/application/.w3c".

Add to this a hierarchical inheritance rule which basically say metadata not specific to a resource can be overriden by subpaths.  For convenience sake, subpaths starting with "_w3c" should be reserved.

Using this solution, my blog's RSS feed list can be located by fetching "https://blog.docuverse.com/.w3c".  Problem solved.

To me, current discussions are no different than discussions about where the toilet flush lever should be placed.  Should it be on the right-side because there are more right-handed people or at the center to be fair?  I say let the manufacturers place the damn lever anywhere convenient and noticeable.  'Users' will do the rest.

SQLLite

While LAMP (Linux, Apache, MySQL, PHP/Perl/Python) is still going strong as a web application platform, MySQL is being challenged as the default database by SQLLite (home, download, wiki).  SQLLite is an embeddable SQL database engine, meaning it runs inside your program.  Beside being embeddable, it has these attractive features:

• Speed – SQLLite is faster than MySQL (benchmark)
• Code Size – just 25K lines of C
• Data Size – much smaller backup file than MySQL
• Data Storage – everything is stored in one file
• Transaction – built-in and default unlike MySQL
• Dependency – SQLLite has no external dependencies

Upcoming PHP 5 will include and use SQLLite as its default database engine.  This PHP Internals message outlines the benefits SQLLite brings to PHP.  Interestingly, MySQL client libraries will no longer be bundled with PHP due to some licensing issues.  I am not sure if this is a major trend in the making, but MySQL is taking the embeddable threat seriously enough to work on its own version of embeddable MySQL (mentioned in the October issue of Linux Magazine).

QDBM

If you don't need to use SQL, Mikio Hirabayashi's QDBM is an attractive xDBM-style (GDBM, NDBM, SDBM, Berkeley DB, etc.) database management library.  This benchmark (PDF) compares QDBM with other xDBM libraries.  It's main competitor is Berkeley DB which also offers both hash table and B+ tree API.  In comparison to Berkeley DB, QDBM has a nice speed/data-size ratio.  Only problem is that QDBM is still in beta.  Hopefully, this post will give the open source project more exposure and attract more resources to it.

This is a non-crypto wack at the spam problem.  It's half-baked at the moment, but I am sure you guys will provide the necessary heat to cook fully or burn it crisp.

Today, e-mail senders have no way of knowing whether a message sent has been erroneously flagged as a spam on the receiver side by either receiver-SMTPs or SMTP clients.  Being able to check whether my message is likely to be flagged as a spam has some value to me.  Starting with that idea, let's see if a solution comes together.

Spam-Filtered Outgoing Mail

A sender-SMTP that uses spam-filters on outgoing messages returns messages flagged as a spam or a likely spam back to the sender instead of sending them, allowing the sender to revise the message or use another communication channel like telephoning.  Sender-SMTP is basically saying that the message is being returned because chance of the message getting through the spam filter on the receiving side is low, a valuable service IMHO.

Sender-SMTP can weed out spammer's mail accounts by monitoring spam ratio on each account.

Filtering spam on the sender-side has two side-effects:

1. outgoing mail volume drops.
    
2. spam ratio decreases.

These effects will be visible to both receiver-SMTPs and mail recipients, meaning less spams for them.  Sender-SMTP can also actively weed out spammers by monitoring spam ratio on each mail account.

Identifying sender-SMTP by IP address

To encourage sender-SMTPs to use spam-filters on outgoing mail, they have to be identified.  One cheap solution is by IP address.

If sender-SMTPs are encouraged to have static IP addresses, receiver-SMTPs can identify sender-SMPTs and rate each accordingly, giving higher marks to those that seems to be filtering spam.  Penalties to those who rate low can range from limiting frequency of connections and/or limiting volume per connection.

To encourage sender-SMTPs to use a static IP address, receiver-SMTPs can apply penalties to unknown sender-SMTPs.  To avoid the penalty, sender-SMTPs must use a senderid assigned to the IP address on first connection.

Recipient Feedback

Receiver-SMTPs can append a URL to each message to collect recipient feedback which can be used to differentiate good SMTPs from masquerading bad SMTPs.  Feedback can be sent as part of receiver-SMTP's response when the suspect sender-SMTP connects next time.  Sender-SMTP can use the information to throttle back the suspect sender's mail volume.

I am not sure if the solution I just sketched will work or not, but it is definitely more scalable than TEN or SMTP4All.  Please let me know what you think.

Update - 2003/10/14 12:32PM PST

 Mitch Ratcliffe is looking at the spam problem from a similar angle:

Push the responsibility back onto the sources of spam, not the end-user who generally doesn't spam one iota.

Right on, Mitch.

While I was getting a haircut today, I thought about the scalability problem of solutions like TEN and SMTP4All.

Digitally signing each message will reduce mail throughput significantly.  Some of the throughput loss will be offset by removal of spam which will reduce message traffic by as much as 90%.  Scalability problem remains still because mail traffic is not constant.

Add to this the cost of bi-directional authentication between sender-SMTP and receiver SMTP.  If messages per session is high (i.e. mail traffic between AOL and MSN), cost will be minimal.  But I suspect the average number of messages per session is pretty low, meaning near one message per session.