Smalltalk Tidbits, Industry Rants

I just posted a new build on the site. There were potential problems with command line argument handling, and those are resolved. Dave Murphy is busy fixing some other bugs, including the problem where some feeds get new items, but don't show up as new.

I spotted this today over on the Syndirella site: visit here to get the full popup treatment...

Welcome to The Buffy Network. It has come to our attention recently that a lot of visitors to this website do not have the correct setting on their computer when they try and access the site. For example, 0.82% of visitors are using Netscape - which does not support the kind of html coding we use. 2.10% of visitors dont have Java installed and/or turned on, Java is essential for some of the pop up windows we use. And 40.76% of vistors are using the wrong screen resoloution. Anything larger than 800 x 600 is too large, and the pages do not diosplay properly. Please try and use the right settings on your computer before entering the site, in order to make it look on your screen, how we intened it to look on ours. Thank you for visiting The Buffy Network. Please click 'Ok' to close this window

And I thought sysadmins had issues with users...

This had me laughing.

HANOI, Vietnam - An airport in central Vietnam suspended plane traffic for two and a half hours because seven cows were blocking the runway, state-controlled media reported Saturday. Two Vietnam Airlines flights from Danang to Ho Chi Minh City were delayed and two other flights from Hanoi to Danang were canceled Thursday night because the cows belonging to army units in the airport area broke free from their corrals and ran loose around the runway, the Lao Dong (Labor) trade union newspaper quoted Luu Van Hanh, director of the Vietnam Airlines office in Danang, as saying. A Danang airport official said Saturday that flights resumed promptly after all the cows had been captured.

I have been working on Pingback today, and I think I have it done. I haven't deployed it yet; that will mean a slight modification to the server configuration (new parcels to load, update to the blog software). Since I have party cleaning to do, I'll get to that later.

I actually had time to test Pingback out on my LAN, so I pushed it to the server. The bottom of each post is starting to look cluttered now; I think I'm going to have to address that. In the meantime, I should be able to send and receive pingbacks now.

A reader asks what these Pingback and Trackback things are. Roughly speaking, they are ways of finding out who is referring to your posts (and for others to find out that you are referring to theirs. Yes, this information is all living in the server logs. However, these mechanisms have the advantage of immediacy - you get notified of a link right away. Trackback is simpler, but more manual. You grab the trackback URL from the site you are linking to, add a few arguments to the URL, and then POST it. The nice part is, it only involves creating an URL and submitting it; no fuss, no muss - but it's manual - you have to remember (when you are creating your post) to list the trackbacks. Pingback is somewhat more complex - you create an XML-RPC server to get hits, and send XML-RPC messages to notify others. In this setup, your blog software looks at all the links you have in your post, and then sees if the servers at those links support Pingback. If they do, you create the XML-RPC message and send it. More server logic, but nothing to remember when you make the post. As of yet, I'm unclear on the real value. But it was easy enough to implement (hey, this is Smalltalk!), and we'll see what happens.

Reflective Surface has an interesting post on Copyright law -

Lawrence Lessig has a new proposal for copyrights. Fifty years after a work has been published, its copyright owner would be required to pay a small tax to keep it under copyright protection. If the tax is not paid for three years, the works is forfeit to public domain

There are additional links, go here to see them

So I'm reading the JSR for Generics. There's a whole lot of weasel words about why support for primitive data types would be a bad idea; I boiled it down to inappropriate concern for optimization. It took more than a page of text to get there, and my head hurt after reading it. Then I came across this:

Supporting generic types at run time seems undesirable for the following reasons:

1. Lack of experience with such constructs in widely used languages
2. Burden of extensive VM changes on vendors throughout the industry
3. Increased footprint on small devices
4. Decreased performance for generic methods
5. Compatibility

Run time support for genericity has not been implemented in any major programming language, and research efforts are also extremely few. Consequently, the body of experience with such constructs is very limited. It is therefore inappropriate to deploy such constructs in a widely used, mission critical language. The risks are too great. Beyond the general principle of relying on well understood technology, the following discussion should make it clear just how big a technological risk is involved.

Now admittedly, Smalltalk doesn't have generics in the sense these guys mean. On the other hand, it doesn't need generics in the sense they mean - it's a non-issue in a language like Smalltalk. What amused me is their assertion that experience with such constructs is limited. This goes back to my whole echo chamber theory of Java and the designers who work there. Heaven forbid that they go and see what people using Smalltalk or Lisp have done.

I spotted this item about Copyright law on the Reflective Surface web log. There's a story in the Post as well:

Congress to lawyers: Don't take away our BlackBerrys. Please. In a rare intervention into a private lawsuit, the chief administrator of the House of Representatives yesterday pleaded with attorneys in a patent-infringement case to settle their differences in a way that allows the popular handheld e-mailing device to continue operating. "The device is used routinely by most members of Congress . . . as well as senior staff," wrote James M. Eagen III. Any disruption in the service "creates a serious risk to the House's critical communications and could jeopardize the public interest, particularly in the event of an emergency," he said.

Yeah, I see how well they like it when the shoe is on the other foot. Could they stay away from my fair use rights while they are at it?

Ronaldo Melo Ferraz has helped me out on Trackbacks, pointing me to the Trackback specs page. Apparently, the geniuses behind this spec released a first version that operates as an HTTP GET (with args passed in the URL) and a second version that operates as an HTTP POST with arguments in the content. Sigh. Moving targets are so much fun.

I added a new RSS Feed for the comments that get added to the blog. I also think I have trackback working now, both for the old style GET and the new style POST. Additionally, I support the Movable Type API for querying trackbacks. At this point, it answers all the comments instead of all trackbacks, but I will get to that eventually.

I just posted a new BottomFeeder build. This one has Dave's fixes to the new item problem. The 2.6 version had a problem with some updating - some feeds would get new items, but not show as new until they were selected. This build should fix that.

It's one of those non-work work days. It's MLK day, a federal (and state) holiday, but not a Cincom holiday. What that means is that my daughter is home, my wife is home (and it turns out her brother is here - we had a party yesterday). So I'm feeling fairly unmotivated at the moment...

I guess the ReplayTV I had so much trouble with was just a lemon. Sonic Blue sent me a new one, and it worked just fine right out of the box. Found the DHCP server right off, changed channels perfectly - everything is cool. If the customer service interactions hadn't been so bad, I'd be perfectly content.

Hat tip to Eliot Miranda for pointing out this cls post I had blipped over:

A poster asks:

I need database access I need all kinds of graphical display Which freely availabe Smalltalk fits these needs? BTW: Why I do not start immediately with Jave / C++?

1. I hope SmallTalk is faster (or at least not slower) then Java
2. I like to try "new" languages"
3. C++ has not garbage collector

(I also think about Lisp + TCL/TK)

And the response is: Note: Many things I say here with respect to VisualWorks are mostly true with other Smalltalks as well. Most Smalltalks have threads (for a long time) even though they may not use native OS threads. Based on seven years of experience with VisualWorks (VW), I would suggest to go with VisualWorks(VW). For the past three years I have been using ControlWorks - a very complex, realtime, distributed, multithreaded framework, tool suite for semiconductor equipment control software developed using VW (www.adventact.com). I am neither part of Cincom or Adventa, just a customer of them. Reliability of VW has been incredible. Thread support is superb. Probably our application could be one of the worst case scenario for testing complex multithreaded architectures and VW has proven over the past three years. We didn't use native threads for valid reason - there was no necessity. VW (and of course in other Smalltalks as well) threads are extremely light. Unlike Java, VW threads work uniformly across all platforms. Thread creation, context switch is much faster than native OS threads ( I have measured these times on Win2k and XP using VC++, Java and VW). Java spec regarding threads is loose, it doesn't clearly tell about thread scheduling or priority and can be problem in some cases for multi platform applications. On Windows, JVM from Sun uses native OS threads. Smalltalk threads support suspend, resume and terminate operations (these operations have been deprecated in Java for few valid reasons). These operations should be used with caution but very handy in few cases (in some cases necessity). VW supports semaphores, critical sections, shared queues for thread synchronization, asynchronous notifications, inter-thread communication. As I mentioned earlier, all these were put to test in extreme conditions in our system. Interactiveness of Smalltalks are incredible, you don't have to stop the application in order to modify code (the only other IDE that comes close is VisualAge Java). All source code will be at finger tips including one for framework classes and IDE tools themselves (no non-smalltalk IDEs can claim that). Reflection capabilities are simply amazing. Any complex UI needs a good visual UI builder and VW has a good UI building tool. You can configure text fields and combo boxes to handle text as well as numbers in various formats with automatic conversions. There is a large set of widgets. All of the VW IDE tools are built using VW widgets and tools. Java Swing also has a large set of widgets. Recently, there has been lot of improvements in performance of Swing. Performance is not an issue in Java or Smalltalk. In some cases Java is better and in few cases VW works faster. Only C/C++ folks think that performance is an issue in Java or Smalltalk. Such conclusions are based on running some trivial test cases. It is very hard to write complex applications in multiple languages and compare the results. If you take VW IDE itself as a complex application written in VW, you will feel the performance and responsiveness of UIs. In contrast, Forte for Java is just terrible with respect to responsiveness and memory footprint. For reasonably complex applications, VW certainly beats Java and MS tools in the memory footprint. Unlike in Java, you can add or modify methods of framework/library classes themselves. This can be a great advantage in many cases but can be a problem in applet environments or getting code from dozen different vendors. IMO, Java should have allowed adding methods to API classes. I would suggest to download VWNC, you will see how responsive and lean the IDE is. You will need some time to get used to environment(tools, libraries etc)since it is radically different from Borland Turbo IDE derivatives (which includes most non-Smalltalk IDEs in the industry).

Was a little sparse. Over on the Smalltalk IRC Channel, it was pointed out to me that the feed did not have enough information. I changed it to include the comment author's name and a link back to the original post.

Overheard in the IRC Channel:

Something you might like to hear. With VA there is high risk for our company every time a new release is made available to the public. We not only have to get our hands on it but we have to make sure all our existing applications still work when moved to the new framework. Inevitably there are changes that break things. Undocumented changes. With the VW-Dev program, if my company were using VW, we could have continual integration against the dev builds to make sure our applications are not going to hit something new that'll break the way our application works. There's no such doppleganger for VA.

And the example:

The offset for all widgets were re-aligned with the windows standard instead of being consistent (ie: text is 15 high and comboboxes are 17 high. Previous versions they were both 17 high). Because we use attachments of widgets to widgets (to allow for multilingual fonts) this meant that all our labels didn't line up with our fields The labels would all be 15 instead of 17 making them progressively slide up 2 pixels at a time offset. As you can imagine, this had a rather large impact on our applications and we had to fix up the problem so that it worked the same as it did in previous versions. That is high risk and worse still it was undocumented. The opinion of management is if it's incompatible, we won't upgrade - so we need to make it feasible to upgrade. When you're hit with something like that, it's hard to argue that we should put in the time to figure it out and fix it.

I found that fascinating. And the VW-DEV Program can keep you up to date on VW changes as we make them!

I have a toolbar for BottomFeeder now. There were some oddball issues with the image creation, but I finally figured that out. If my connection stops being flaky, I'll post a new DEV build.

I saw this post on the 0xDECAFBAD blog.

It seems that beyond carrying syndication information, RSS is a very useful and flexible way to get all sorts of application data pushed to a user over time. In the same way that a web browser is a universal canvas upon which limitless services and information can be painted, so (in an albeit much smaller way) an RSS reader/aggregator might also find its place as an inbox for time-related delivery of all sorts of information.

go read the whole thing

I am posting a new build of BottomFeeder now. After adding the toolbar, I noticed some anomolies - since it is generated from the menu we use in the feed items list, options were not always appropriate (for instance, if a folder was selected). I fixed that. I also added a requested feature while I was in the code - you can now add feeds or feedlists while offline, and they will be appropriately updated when the tool is put back online. Enjoy!

I caught this piece on the Truth Laid Bear blog:

Have you ever noticed how stunningly inappropriate some of the advertisements which appear on the pages of Slate can be? If they are using any kind of logic to present ads appropriate to the readership of a given piece, then it has to be the worst such system ever created, as the advertisements seem to be utterly random. But this can lead to amusement: in a moment of boredom, I decided to make it a game. (And you can play along at home, too!) What's the most inappropriate pairing of a Slate piece and its accompanying advertisement that can be found?

To be fair, I've seen other pathetic examples elseqhere. But it's still funny...

I was looking over my feed update this morning when I came across this item from the Loosely Coupled blog. It seems that Oracle has put Do it yourself portal capabilities in their latest release, and this has some of the control freak types upset:

The launch this week of DIY portal capabilities for Oracle's application server platform has not been welcomed in all quarters. According to Forrester analyst Nate Root, quoted in Internet Week, "Portal development isn't a business-user function. IT doesn't want it to be a business-user function ... The way to break the development bottleneck is to give IT better tools, not try to circumvent IT."

In my experience, the typical IT group wouldn't know a business function if it walked up and bit it on the nose. There was an encouraging thing in this for me; it showed me that I'm not the only business user who sees the words value and IT Group put together in a sentence and starts snorting whatever beverage he has at hand...

Richard Gabriel, author of Worse is Better, gave a talk last November title "Objects have Failed". The talk may be found here. I find this narrative interesting:

Objects, as envisioned by the designers of languages like Smalltalk and Actor - long before C++ and Java came around - were for modeling and building complex, dynamic worlds. Programming environments for languages like Smalltalk were written in those languages and were extensible by developers. Because the philosophy of dynamic change was part of the post-Simula OO worldview, languages and environments of that era were highly dynamic. But with C++ and Java, the dynamic thinking fostered by object-oriented languages was nearly fatally assaulted by the theology of static thinking inherited from our mathematical heritage and the assumptions built into our views of computing by Charles Babbage whose factory-building worldview was dominated by omniscience and omnipotence. And as a result we find that object-oriented languages have succumb to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair

Now the ironic part: Richard Gabriel, distinguished engineer at SUN. I find this fascinating. The quote above effectively states that things like Java are part of the problem. And there he is, at Sun.

BottomFeeder has updated documentation, thanks to Rich Demers. Just pull down the Help>Users Guide menu item, and you'll browse the latest. Thanks to Rich for a great job!

But I am still baffled on my efforts to upgrade the server. Something in my new codebase blows up on the server, but works fine on my testbed. Sigh...

Interesting article on the O'Reilly site - Timothy Appnel writes that RSS is more than a syndication format - and is being used as a proto-web service. If you follow the early users of RSS, you'll see that - Pingback and Trackback are effectively web services enabling backtracking. Various blog tools support updates via other RSS features. Here's what Timothy writes:

DJ Adams writes: It seems that beyond carrying syndication information, RSS is a very useful and flexible way to get all sorts of application data pushed to a user over time. In the same way that a web browser is a universal canvas upon which limitless services and information can be painted, so (in an albeit much smaller way) an RSS reader/aggregator might also find its place as an inbox for time-related delivery of all sorts of information.

Amen DJ! As I asserted in a previous weblog post, Web Services We'd Like To See, I wrote Whether it is just assumed or simply overlooked, RSS is the most widely deployed Web service across the Internet. Granted, most RSS feeds have very simple interfaces with almost as simple backends that are unlike the Web services that usually come to mind. (Who says Web services need to be complex or sophisticated anyhow?) Under the principles of the REST architectural style that the Web was built on, RSS feeds do qualify. Consider that any site search engine becomes a Web service if it could emit results in RSS and the format's potential in the realm of Web services becomes more apparent. It is this perceived potential that I've been an advocate of getting the RSS format's house in order.

I can vouch for the value. I started monkeying around with RSS at the end of the summer, and Dave Murphy joined in and wrote the user interface for BottomFeed. Over the next few months, our engineering group added RSS feeds for our bug tracking tool (2 - one for all AR activity, and one for newly closed items). We added feeds for our source code databases. I added a feed for our public wiki and for this blog. I can see further possibilities as well; a nice, easier to use client interface to some of the cruftier web based tools out there, for instance. In any case, go read the whole article

I published the XML-RPC code that I got from Roger Whitney into the public store this evening. This is the code I used to get Pingback (which uses XML-RPC) working with the blog. This version was Wave (not Web Toolkit) based, and also came from VW 3 - so it does not use the stock VW XML parser. The code could use a port to the features of VW 7, but these initial hacks got me going.

I posted on RSS yesterday - and Steve Waring linked to it here. Today, I started catching up on the news in my feedlist when I came across this post from Mark Pilgrim:

As I said in last month's article, RSS is an XML-based format for syndicating news and news-like sites. XML was chosen, among other reasons, to make it easier to parse with off-the-shelf XML tools. Unfortunately in the past few years, as RSS has gained popularity, the quality of RSS feeds has dropped. There are now dozens of versions of hundreds of tools producing RSS feeds. Many have bugs. Few build RSS feeds using XML libraries; most treat it as text, by piecing the feed together with string concatenation, maybe (or maybe not) applying a few manually coded escaping rules, and hoping for the best. On average, at any given time, about 10% of all RSS feeds are not well-formed XML. Some errors are systemic, due to bugs in publishing software. It took Movable Type a year to properly escape ampersands and entities, and most users are still using old versions or new versions with old buggy templates. Other errors are transient, due to rough edges in authored content that the publishing tools are unable or unwilling to fix on the fly. As I write this, the Scripting News site's RSS has an illegal high-bit character, a curly apostrophe. Probably just a cut-and-paste error -- I've done the same thing myself many times -- but I don't know of any publishing tool that corrects it on the fly, and that one bad character is enough to trip up any XML parser

I can certainly feel for this problem. With BottomFeeder, we have had to catch lots of complaints from the VW XML Parser. We generally let them go by and continue on - because if we just rejected the feeds when they were invalid, there are precious few feeds that we would support. Marks goes on a bit further down:

There is a social solution to this problem: register at Syndic8.com to be a "fixer", and volunteer your time contacting the authors of individual sites to get them to fix their feeds. There is also a technical solution to this problem: don't use an XML parser. I know, I know, this is heresy. The point of XML is that content producers are supposed to put up with the pain of XML formatting rules so that content consumers can do cool things with off-the-shelf tools. Well, guess what? It's not happening. Judging by the sad state of affairs in the RSS world, content producers are either ignorant of the error of their ways, or too lazy to fix the errors, or too busy, or locked into inflexible tools whose vendors are too busy... Whatever the reasons, content consumers are rarely in a position to solve the problem. So we must work around it. We need a parse-at-all-costs RSS parser.

It's an interesting article with some controversial ideas. I think Mark's right though - we are headed down the road to heck, where we will end up with tools that deal with just about anything that stumbles by calling itself RSS - not unlike the current HTML mess...

This is amazing to me.

THE classic Beatles' Abbey Road album cover showing the band on a zebra crossing has been altered - to remove the cigarette in Paul McCartney's hand. The original image shows a barefoot Macca third in line holding his ciggie. The 1969 photo has been a poster best-seller since it was shot near Abbey Road studios in North London, where the Fab Four recorded most of their music. But companies including US giant Allposters asked for the cigarette to be removed by computer wizardry to make it more politically correct.

Wow.

I spotted this item via Gordon's log.

The trouble with XP is that its just the type of dogma that appeals to jerkoffs. And hence they want to letter of the law everything to the point where it has no meaning while violating its spirit. I think peer-programming is Awesome provided I get my "me" time and I find someone who's working style complements me. (which is my nice way of saying, "cold day in hell: ;-)) I've peer-programmed remotely quite successfully.

The post is actually not anti-XP - it makes some good points. I agree with Gordon:

That's the trouble with any methodology, I don't think it's a problem unique to XP.

I've also paired remotely - with BottomFeeder , we've used an IRC channel to communicate.

Catching up on my feeds this afternoon, I stumbled on this. Good thing I wasn't having a beverage:

SBC Communications Inc is enforcing a patent it owns that, it claims, covers the use of frame-like user interfaces in web sites, it emerged this week Kevin Murphy writes. . If your web site uses a frames or a persistent user interface, then you could be in infringement. Using SBC's interpretation of its patent, hundreds of thousands of web sites, including those of many SBC's own hosting customers, many of the web's biggest sites, and the United States Patent and Trademark Office itself, could be in infringement.

This is just insane. What next, books? Get the whole story from the Register

I've posted before on why I think Sun has problems. Here comes another story on that subject:

NEW YORK--Dell Computer has switched 14 of its internal servers from Sun Microsystems machines to its own systems running Linux and a new version of Oracle's database software, Chief Information Officer Randy Mott said Thursday. The new systems, which spread the database across a "cluster" of interconnected lower-end machines instead of using a single more powerful system, cost less and work faster, Mott said in a keynote address at the LinuxWorld Conference and Expo in New York.

That's got to hurt

Or, Why Java sucks for XP Go visit this Sun page. After I picked myself back up (ROTFL), I grabbed this text:

Suppose that you want to add some functionality to StockWatcher. For instance, suppose that you want to add a method that reports the current stock price, regardless of whether the value changed:

 
public interface StockWatcher {
    final String sunTicker = "SUNW";
    final String oracleTicker = "ORCL";
    final String ciscoTicker = "CSCO";
    
    void valueChanged(String tickerSymbol, double newValue); 
    void currentValue(String tickerSymbol, double newValue); 
}

However, if you make this change, all classes that implement the old StockWatcher interface will break because they dont implement the interface anymore! Programmers relying on this interface will protest loudly. Try to anticipate all uses for your interface up front and specify it completely from the beginning. Given that this is often impossible, you may need either to create more interfaces later or to break your customers code. For example, you could create a StockWatcher subinterface called StockTracker that declared the new method:

public interface StockTracker extends StockWatcher {
    void currentValue(String tickerSymbol, double newValue);
}

Now users of your code can choose to upgrade to the new interface or to stick with the old interface

Read that again: Try to anticipate all uses for your interface up front and specify it completely from the beginning. Given that this is often impossible, you may need either to create more interfaces later or to break your customers code So, YAGNI isn't possible, and using Java interfaces demands that you over-build up front. Bah.

David Buck pointed me to a thread on slashdot. I had noticed, but I rarely delve that deeply into the slashdot threads. Dave points out two interesting replies: From the "Java is great (but they don't realize Smalltalk does it better)" camp and From the "They just don't get it" camp For instance:

no stack objects; I don't know the internals of the stack management and the complexity of C++, but since C++ managed it, why not Java ? why should I have to create an object on the heap just to use it locally ?

As Russ Pencin used to say in Smalltalk classes, Why do you care? or this:

I don't know why the garbage collection is such an advantage. In the place that I work we have written apps with milions of lines of code using C++ and we never had a problem with memory leaks. Of course, being military and scientific apps, there was a good design before coding, so we had a pretty good knowledge of when to allocate/free stuff. But it is not hard to make C++ objects garbage-collected. All that is needed is a base class that upon its construction puts the object in a global list and a template pointer that increases/decreases automatically the reference counter of the garbage-collected object when assigned to it; later, the list will be traversed and objects with no reference will be deleted.

Chuckle. Either he's effectively written his own GC system and doesn't realize the sunken investment, or he's just clueless. Then there's this:

For the second point, I don't like either interpreted or byte-code languages with virtual machines. I think they are a waste of CPU time and resources. I am 100% certain that there is no point in having static Java apps executed by a virtual machine: they are very slow, even with top-of-the-range Pentiums. And when we say slow, we mean slow enough for an experienced user to handle: for example, I have personal experience of a versioning and control application that we use at work which is very slow, although it runs on a P4 at 1.8 GHz. It may not be slow, but it definitely feels slow.

That's right, one badly written app condemns an entire paradigm. Why doesn't he write machine code?

I posted a new DEV Build - there was a bug that prevented look policies from being restored at startup.

I posted yesterday on this, and this morning this pops up in my feed list from Linux Today:

In the short term, Linux is mainly a threat to companies that make computers based on variations of the Unix operating system, the dominant system driving corporate mainframes and servers. But the company that could eventually find itself in the line of fire is Microsoft, whose position in the computing industry rests heavily on its Windows family of operating systems. "We see Linux going over the moon," says Larry Ellison, chairman and chief executive officer of Oracle. "We have never seen anything with this much of an uptake in 25 years in the industry..."

Now I don't necessarily take Ellison as an authoritative source - after all, he was sure that network computers were going to overtake Windows. Still, the signs don't look good for the Unix vendors. Especially since IBM is on the Linux bandwagon...

Rich Demers has found a few more bugs, and made some more suggestions. A new DEV Build is up.

This is why we don't use SQL Server for the Cincom Smalltalk server.

"Since about midnight EST almost every host on the internet has been receiving a 376 byte UDP payload on port ms-sql-m (1434) from a random infected server. Reports of some hosts receiving 10 per minute or more. internetpulse.net is reporting UUNet and Internap are being hit very hard. This is the cause of major connectivity problems being experienced worldwide. It is believed this worm leverages a vulnerability published in June 2002. Several core routers have taken to blocking port 1434 outright. If you run Microsoft SQL Server, make sure the public internet can't access it. If you manage a gateway, consider dropping UDP packets sent to port 1434." bani adds "This has effectively disabled 5 of the 13 root nameservers."

Sooner or later, some attack is going to take down a critical mass of those root servers, and no one will be able to see anything.

I posted this morning on the worm that was apparently slowing net traffic; there's also a CNN Story on it. If you point your browser here, you can see what purports to be a "health" meter for the internet, showing a distinct problem this morning. I found all this refs here. As I said this morning, I doubt things are going to get better in this regard anytime soon.

It is often the case that applications - be they client applications, or server applications - need to make network connections via standard internet protocols. VisualWorks supports a wide variety of such protocols, including HTTP and HTTPS. It's becoming more and more common for applications to expose what some call REST (REpresentational State Transfer) as a way of opening up some of their internal API's to the world.

What, do you ask is REST? Simply put, it's an HTTP based interface to an application. While that sounds complicated, it's not. For instance - searching my web log for information on REST could take the form of this HTTP based query:

http://www.cincomsmalltalk.com/blog/blogView?search=REST&searchTitle=true&searchText=false. The interesting thing is, the results of a query like this need not be parsed solely by a web browser - they can be parsed by an application that doesn't even expose the results directly to the end user. Now, this is a simple example - the query above is a GET, and the results come back in the HTML body as text. What if you have a more complex interface?

Using my weblog again as an example, let's look at exposing POST interfaces. In the weblog and RSS world, there's growing interest in being able to trace posts, comments, and related posts on other web logs. Two examples of this are Trackback and Pingback. Both are interfaces that accept HTTP POSTS from clients. Handling those in a VisualWorks server is easy; you just create a servlet, a post handler, and grab the form elements. But what about the client end?

In the RSS/Web log world, a web log should not only be able to receive these notifications, but be able to send them. How do you create a POST in code? Very easily, as it turns out. Using the NetClients libraries, here's an example of creating and sending a trackback POST:

doPostTBFor: tbToSendUrl from: entry
	| client content |
	client := HttpClient new.
	content := self postTBFor: tbToSendUrl from: entry.
	request := HttpRequest method: 'POST' url: tbToSendUrl.
	request referer: entry getPermaUrl.
	request contents: content.
	request contentType: 'application/x-www-form-urlencoded'.
	^[client executeRequest: request] on: self httpExceptions
		do: [:ex | ex return].

In this example, #postTBFor:from: looks like this:

postTBFor: baseUrl from: entry
	| stream settings excerptLength myUrl |
	stream := WriteStream on: (String new: 500).
	settings := BlogSaver default settings.
	excerptLength := entry blogText size min: settings excerptLength.
	stream nextPutAll: 'title=', (entry getHTMLEncodingFor: entry title).
	myUrl := settings mainLink, '?entry=', entry timestamp asSeconds printString, '&showComments=true'.
	stream nextPutAll: '&url=', myUrl.
	stream nextPutAll: '&excerpt=', (entry getHTMLEncodingFor: (entry blogText copyFrom: 1 to: excerptLength)).
	stream nextPutAll: '&blog_name=', (entry getHTMLEncodingFor: settings blogName).
	^stream contents

What I've done here is created a POST object, set the type to 'application/x-www-form-urlencoded' - which will allow the remote end to interpret it as a form being posted - and then placed the URL-Encoded form data in as the contents. That's the second method. Note that the code is simple streaming; I just create the URL-Encoded data manually. If this is something you need to do a lot of, you could pretty easily add convenience protocol to automate this.

In any case, using the above two methods, my web log sends trackbacks and pingbacks whenever I refer to an enabled site in a post. It's all pretty simple - a few lines of simple Smalltalk code, and you have an interface into any site on the web!

I posted on some issues in RSS the other day. It's been a widely discussed topic; I saw this just now on Reflective Surface.

But there are still some problems. Obviously, not all tool developers care about generating well-formed feeds. Some even have a history of providing feeds that are almost garbage, if feeds are provided at all. That's the problem I see with any solution other than parsing at all costs: it may be harder to convince some providers to create tools that generate correct XML than write liberal parsers. And even if those developers could be convinced, there are still large amounts of deployed tools that won't be upgraded and will continue to generate invalid feeds. I don't like this situation. As Dare Obasanjo said, it's quite depressing. XML was supposed to bring a new age to information processing. But real life is always different, and now we must deal with those problems in a way users can benefit. After all, there is no point in creating technology that cannot add value to people lives.

So it is back to the future, just like the wild world of HTML - wild variations and client front ends that have to handle just about any darn thing that comes their way.

This post on Sam Ruby's blog, and this one on Ken Coar's blog got me thinking. Are there any bloggers in the greater Washington DC/Baltimore area interested in a similar get together?