Smalltalk Tidbits, Industry Rants

The difference between good writing, and bad writing....

Ok, I have to admit - the opening was cool. But still, I find that the series has mostly lost my interest - it just got too wacky this last season. This episode looks pretty cool - looks like they put it back together for the end. Then there's the fact that one of the plot sidebars has been completely overtaken by current events, but nevermind.

Well, it's clear that the series wasn't intending to end there. Irritating....

I've posted a new BottomFeeder Dev Build. There are two new platforms available - Linux PPC and Linux Sparc. These platforms are not formally supported in VisualWorks (on which BottomFeeder is built), but this is a good way to test out the platform. The latest TypeLess is part of this as well. I have not updated the TypeLess parcel in the BottomFeeder upgrades directory - it requires the new base image I just built. Give it a whirl and let me know what you think!

What does the chapter 11 filing of SonicBlue mean for the ReplayTV?

Life without ReplayTV. Shudder

and also cleaned the back end code up as a result. There's more I'd like to do, but I have to actually go figure out style sheets for that. I've been putting that off for awhile now....

For your input. If you haven't given us feedback, please do so here

I taught the last Smalltalk class for the winter today - I've been using Squeak to introduce 4th and 5th graders to programming. We had a look at EToys today, and we went through the make your own car tutorial. The kids picked it right up - after I walked them through the car, they were able to add the steering wheel and get going. They had a lot of fun, and learned something while they were at it. I'll be better prepared next time, and start with the EToys stuff.

Eliot Miranda posted up an explanation of the VW threaded API call mechanism. While this is a feature VW has had since 2.5.2, many people still seem to not know about it....

Scott Johnson is not amused by ATT support:

I start to traceroute and give him feedback about the broken routes. I ask him: What's an email address so I can mail it to you? "I don't have one". What's a hot mail account I can send it to? "I can't give that to you either." So I ended up reading him the bad routes. Pathetic. And this from a company that sucks $50 from me monthly for broadband?

I finally give him the info, he checks it from there after a 5 minute hold session and B I N G O ! I was *right*. They have a problem on their internal network and then I had to wait on hold for another 5 minutes while he filled out a trouble ticket. Then I got the really bad news.

"It'll be resolved within 72 hours. Not necessarily fixed but hopefully a solution decided upon." What the fsck does that mean ? That within 3 days from now, you'll decide how to fix it and then take as long as you like? Utterly, totally pathetic.

Yeah, I've had to explain networking to Comcast before - and trust me, I am no networking wizard. Just say the word "Linux" to a Comcast rep and watch them try to claim that it's all your fault, even when the problem is signal strength. And then there was my happy times with Sonic Blue support. Are these vendors just trying to drive us away?

Over Here. Cool!

At least, once this sale goes through

Navigate your way here and have a look. There are many more details in the Release Notes, which will ship with the product. Make sure to have a look at those after 7.1 ships

Camp Smalltalk 6 is gearing up, June 22-26 in Germany. Have a look at the projects, the attendees, and the registration. There are tips for getting to CS6 here. I won't be going - Smalltalk Solutions is shortly afterwards, and the schedule for CS6 doesn't work for me - my daughter's summer vacation will just be starting then. Looks like a good camp though!

I'm preparing for the last Smalltalk class for this group of kids - I'm going to have them work on this today. We worked on extending the demo last week - this week, we will work on creating it from scratch. The kids should enjoy that.

I'm teaching this again in a few weeks, and I think I'll start with the EToys stuff right off the next time. It's fun for the kids, and also gets them experimenting. Highly useful stuff!

This post pounts to some good guidelines for development. While they are aimed at Java, the design goals - numbers 1-35 at the beginning - are applicable to Smalltalk as well. For that matter, easier to accomplish in Smalltalk....

While watching the wall to wall war coverage, I found and fixed a nastly little bug in the 2.8 code. I was missing a method implementation! Found that in testing. Hopefully, no more of those lurking on the code....

Then I saw these pictures from the Denver storm. Wow

I can point to two things:

• This document on migration issues
• If that doesn't convince you, look at this from comp.lang.smalltalk

Here's some Smalltalk code:

aminoAt: aString
     ^self aminoList detect: [[:amino | amino name = aString] ifNone: [[nil].

Now the equivalent C#

public CodonAmino getAmino (string aName)
{
    bool found = false;
    CodonAmino amino;
    IEnumerator e = this.AminoList.GetEnumerator();

    while ((found == false) && (e.MoveNext()))
    {
        amino = e.Current;
        found = (amino.Name == aName);
    }
    return found ? amino : null;

The extra typing alone.....

And doing bad things with HTML while they're at it. Go see what Scott Johnson has to say on this:

Someone needs to teach the "gotdotnet" folks what RSS is. Also I couldn't believe their HTML source when I was poking around. So get ready for a vent.

Go look here and look at the __VIEWSTATE input element. To me that's just plain lame. Use a session, send a cookie and use your horsepower for this, not my bandwidth with every page view. And if you really want to barf then click around a bit and go here. They seem to be encoding the entire viewing history in a really nasty way and shipping it back to you every single time. It just gets bigger. After navigating thru like 3 pages I had 6,554 bytes sent down the wire that did nothing for me. Thanks for nothing.

I guess its not all that bad actually but it just seems damn silly. I hope that's not a dot net feature but I'm afraid that it is. Sigh.

Just look at the kind of crusty HTML produced by Word when you do a "Save as HTML". Bleah...

I said this morning that we had one issue that we knew had to be dealt with before we ship VW 7.1. well, engineering found and fixed that issue, and the fix is in code review. There's a build going forward today that won't have that fix, but it loks like we are down to the last little bits here. This is going to be a great release!

As he posts here. Yeah, I've been there with the mini-van. Last year the engine light started blinking periodically. Oil was fine, nothing else seemed to be wrong - and the mechanic I trust couldn't find a problem. It turned out to be one of the sensors in the engine giving a bogus reading, and that required replacing the sensor. It cost way more than was reasonable - and they tried to baffle me with BS on the whole deal, telling me that replacing a chip was complex. Get ready to open the old wallet Matt....

The next release of Cincom Smalltalk is getting close. There was a last issue with menus on the Mac (OS 8 and 9 only) that we were having trouble tracking down, but my email tells me that we have a fix for that. That means that release by the end of this month looks good

BottomFeeder 2.8 will go out as soon as VW 7.1 does - I don't want to ship on a pre-release, and I would like to have the "goodie" parcels in VW match an actual release.

Meanwhile, check out this page to see what's coming!

Got caught by a silly lazy intialization bug - the method that answered a collection of urls to send web log pings to after each post was just answering self, and that caused entertaining problems. fixed now, and I should be pinging all the usual suspects again. Ahh, the joys of on the fly updates....

The traffic in the DC area has been utterly snarled ever since this started. I sure don't need that kind of thing adding to the joy of drive time...

Willow is on Angel tonight!

Gotta get those priorities straight....

Have a look at the Smalltalk Solutions site - things are gearing up for the show. We have a nice set of presentations, and the program team is in the process of sorting out, organizing, and scheduling them. Sign up to attend now!

I posted yesterday on security and posting - the Blogger API in particular just passes usernames and passwords in the clear. I'm following the CommentAPI discussion on various blogs - mostly here.

The theory seems to be to replace various ad-hoc HTTP posting methods with some XML based posting/comment API. And again, security has gone missing. Sure, comments don't need a security story. But posts - updates and new - need authentication of some sort or another. I encrypt everything in my tools.

Come on people, get serious!

I've considered adding support for the Blogger API for awhile now. It's not hard; I could get that working in no time flat. I have a rather hard time with one aspect of the API (1.0 and 2.0) though - Usernames and Passwords are passed in the clear. You just create an XML doc, shove unencrypted user info in there, and send it across the web. Well.

Unfortunately, many people use the same password for everything. So right off the bat, the Blogger API just asks for trouble. Not to mention that a popular blog could easily get masqueraded posts that way.

So thus far, I've said no. I create a form, encrypt all the data, and URL encode it. That gets sent to the server from my blog tool, and the servlet there decrypts and validates it. Much better. I guess what I want to know is, why in the heck doesn't the new blogger API specify encryption?

Clarence Westberg rediscovers the ease of Smalltalk, and gives us some advice:

Day 2 of smalltalk programming, I forgot just how productive this is compared to 'C' style programming (like C#). I can actually do what I want without wasting development time figuring out why a cast didn't work or what type something needs to be. I hate typed languages. I also don't have to declare what I am 'using' and all that other compile crap. I wish Cincom would get the smalltalk dll stuff done so I could do as little coding as possible in C#. I do like how easy it is to make a web service in C# though. It would be nice if I could create a class i smalltalk and have something generate all the plumming.

We are in the process of building tools for all that nasty WSDL stuff - a rough cut will arrive with 7.1, with better to follow. 7.1 is due soon.

I've added a Feedster search option to the blog - check out the top of the page and try it out!

it works again. I suppose it's time I set up a local blog ping server for testing before I run live with stuff like this ;-)

We have posted a new Cincom Smalltalk Survey - the topic this time around is web application development.

Results from past surveys may be found here

Thanks!

On each post here, I'm now pinging (as per this spec) the following sites:

• weblogs.com
• blo.gs
• Blogrolling.com

Those are the ones I know about; my ping interface is extensible to an arbitrary list of supported interfaces. Is there anywhere else I should be pinging?

So I'm reading Ted Neward's post on AOP. I highlight AOP, and hit the Feedster it! menu item. Bam, I get a list of other blog entries on AOP. Very cool. If I was writing an entry of my own on AOP, I'd have all the necessary material immediately at hand, in one tool.

I got a great suggestion this morning from Jason Ayers for BottomFeeder - allow the user to select text in the html pane, and immediately execute a Feedster or Google search on the selection. So I added that just now, and the new version of the parcel is already uploaded. I'll do a dev build for the whole thing later.

So now, you select some text, and can immediately do a contextual search on it in blogspace. Now that's cool

From Irrational Software. This is a really good explanation of where and how XP will and won't work:

Laurent Bossavit's article The Unbearable Lightness of Programming: A Tale of Two Cultures (unfortunately no longer available onlineavailable here as PDF) is very good. He looks back on two failed Extreme Programming (XP) projects (at two different companies) and finds the reason for the failure in the organizational cultures clashing with XP. He examines the cultures and what it was about them that caused the clash.

Also interesting was David Putman's article Are You Mature Enough for XP? (not available online) where he identifies two extremes: emergent and enforced cultures. An emergent culture is, basically, one where both employees and management have the power to influence the culture. In an enforced culture, management defines the culture, with little or no possibility for employees to influence. Putman writes that an emergent culture is required for XP to work.

That's an excellent point - your corporate culture has to be XP enabled before you have any chance of success with it. Go read the whole thing - there's lots of good stuff there

The DC XP group is using VisualWorks NC for a codefest - the project we picked is a blog implementation. I bet the code ends up being cleaner than the code that runs this blog ;-)

I was going to comment on this post by Ted Neward, but decided that this comment said everything that needed to be said about it:

And believe it or not, there are some people who fall in a mysterious third group, that I call "competent developers"

Thank goodness I didn't have a full cup of coffee when that went by on the IRC...

then it's due to a patch I briefly put out and removed. Here's the fix:

• Remove the file BtfFeedster2.7Patch.pcl from the BtfPatch directory
• In the btfSettings.ini, change the line that reads patchSiteFilename='patches.xml' to patchSiteFilename='patchDefinitions.xml'

I apologize for the problem...

There's a whole lot of good information on it over here

I've been using client side posting tools with my blog for awhile now, but had a problem with the URL Encoding - on the server side, I was doing two unencodes. This caused obvious problems with '+' signs and '%' signs. Figured out the silly error and patched it up. I figured out that I had a problem when my earlier post changed all the '+' signs to spaces, and made it look like I was referring to C rather than C++

Ted Neward has a post up on OO. He's got a lot of cynical thoughts today:

Languages like C++ and Smalltalk were going to enable a revolution in the industry: Object-orientation was going to make it easy to build complicated systems out of atomic parts, solve world hunger, bring about world peace and make us all rich. For quite a while there, if you didn't throw the term "object-oriented" into a conversation, you obviously weren't a hip developer or manager and therefore obviously weren't worth listening to.

Ten years later, and we're still waiting for the object utopia promised us. It's not like we can blame the languages, either--several additional object-oriented languages, most notably Java, emerged over time, and still no utopia. Vendors even sought ways to put object-oriented extensions into other places, like the relational database (but this was only when object-oriented databases themselves failed to materialize in any large-scale way), to no avail. The promised "object marketplace" just never seemed to happen--certainly object-oriented frameworks (like MFC, OWL, and several other libraries) came about, but these weren't "objects", but basic technology-specific scaffolding for building more objects. Where was the "object palette"? Where were my "SavingsAccount" object and my "BankTeller" object and my "ArcadeGame" objects, that I could just reuse and extend as necessary? It's as if objects failed us somehow.

Let me disagree strongly with the "can't blame the languages" theory. C++ was and is a crappy way to do objects. It's a mixed metaphore language, neither fish nor fowl. Primitive data types get in the way of clean object models, and the lack of garbage collection gets in the way of decent object models. Then we have Java - it adds in gc, but still has primitive data types, and makes a few more horrible mistakes:

• Final classes
• No extension mechanism

Java is fundamentally broken from an OO perspective. I suppose one can do OO in it, but the language (and C development culture) sure don't help you move that way. Ted's just wrong - we can and should blame the languages.

Then he goes on this riff:

Even worse, the marketplace grew around a decidedly non-object-oriented technology. Starting with its 3.0 release, Visual Basic, the butt of programmer jokes, that "technology to keep journalism majors employed", that language that wasn't even object-oriented, for heaven's sake, saw a huge, multi-million dollar industry spring up almost overnight around selling "things" that could be dragged, dropped, and reused without hesitation. This was a language that was developed around BASIC, for crying out loud--no implementation inheritance, no pointers, no overloaded methods or even basic encapsulation. And yet, it was reaping the benefits of binary reuse left and right. It was like watching the dorky guy at the dance, the guy wearing the red-and-green plaid tuxedo, go home with the prom queen.

You can pretty much see the problem with the C language crowd and OO here - (and they call us Smalltalkers arrogant!) - pointers are part of OO? The syntax (Basic, in this case) is disqualifying? (Only curly brace languages may apply, apparently!).

And this:

GUI frameworks, like MFC, succeeded in capturing a significant portion of the complexity associated with building GUI applications, but not in the way objects were originally envisioned. We thought we could just inherit from a base class, thus reusing that base class' functionality, but found that when the next version of the framework shipped, everything broke for some reason.

Broke for some reason???? How's about lack of care for backwards compatibility on the part of the vendor? This has nothing to do with OO - more of a vendor culture issue, IMHO.

Ahh, now here come the not terribly well informed criticisms of Smalltalk:

The first problem, the idea that reuse was achieved via inheritance, was originally conceived out of experience with the only other serious object-oriented platform at the time, Smalltalk. In Smalltalk, all reuse was done through inheritance--if you wanted to make use of a class, you inherited it, and added whatever specialization, overriding, or new behavior desired. Unfortunately, while this works in a loosely-typed environment like Smalltalk, it doesn't work in a strongly-typed one like C++ or Java. What results is a nightmare scenario where the base classes in the hierarchy can rarely, if ever, be modified without breaking (usually in spectacular fashion) every single one of its implementation derivatives. This was commonly called the fragile base class, or FBC, problem. In the long run, it prevented successful evolution of base classes once released into wide use.

Yeesh, where to start. Loosely typed? Sigh.... How many times can we point out that C++ is loosely typed, while Smalltalk is strongly typed? People consistently mistake manifest typing for Strong typing. You would think a few core dumps along the casting path would have taught them, but no....

Then, the statement - "if you wanted to make use of a class, you inherited it, and added whatever specialization, overriding, or new behavior desired. Unfortunately, while this works in a loosely-typed environment like Smalltalk, it doesn't work in a strongly-typed one like C++ or Java". Hmm. Apparently, Ted's not seen class List in VW, or any of a number of other delegation examples. Sure, languages like Self make delegation easier. But it's used quite heavily in Smalltalk. Developers figured out a long time ago that deep inheritance trees tended to have issues - and it's not simply because of Manifest typing.

Regardless of the actual implementation or API of the collection class, it's a well-understood pattern that obtaining the items within the collection should be done through an alternative, separate object instance--an iterator. The iterator focuses on traversing the objects contained within the collection, and has implicit "deep" knowledge of the container's internals to enable this. And here we see the problem of reuse at an object level: these two objects make no sense without one another.

Hmm. We don't have this separation in Smalltalk. Closures, anyone? And in case we thought the industry might be learning, C# has no closures either. To paraphrase the old riff on DOS vs. Unix - Here's a nickel kid - buy yourself a real OO implementation.

However, his riff on Component reuse makes sense:

Quietly alongside the object revolution, a second revolution was also taking place. Born out of the object revolution but focusing more on solving a different set of problems, the idea of building mostly-independent "things", called components, began to take shape. These would be "things" that were of larger granularity, completely self-contained and reusable without any sort of inheritance relationship. Microsoft's Component Object Model was one of the first technologies to embrace this idea completely, and was often criticized roundly for it: because COM focused on building components rather than objects, COM was often denigrated because it offered no mechanism for allowing implementation inheritance, a key cornerstone in "object-oriented" approaches. Unfortunately for the object purists, COM's viability got a huge boost from an unlikely source: Visual Basic. After demonstrating that the "VB control" concept was in fact a viably useful one (as witnessed by the market that sprang up after its 3.0 release), Visual Basic then took the step of effectively abandoning the 16-bit VBX format it created in 3.0, and moved to a 32-bit, COM-based OCX (Ole Control eXtension) format for VB 4.0. This in turn was simplified to create the ActiveX control, which could be either visible or invisible, and later embedded on an HTML page for downloading across a network.

It's the same critique I used to make of PARTS - that individual widgets in a GUI were not really the right level for wiring. Same thing here - individual objects are not the right level for reuse either. We are starting to see some coarse grained reuse in some of the open source projects I'm associated with - BottomFeeder, TypeLess, and Pongo. In our case, it tends to be at the package (component) level.

Go read the whole thing - the component discussion at the end is interesting.

My RSS feed now validates again. You can check here

It turns out that my RSS Feed wasn't validating here. I've patched the code up and tested it, and should be posting it up soon.

So I come back to my PC after shopping - somehow, it's decided that it should hibernate after 30 minutes when plugged in. I had explicitly turned that off. Well, after it came back, my network connection was frelled again, because the settings had (inexplicably) toggled again.

I am not a happy camper....

While I generally like Windows XP (Pro), there are some real oddities. my wife's machine (XP Home) still will not share devices; it's completely unclear why. There was no change made to her machine or the network; one day it just up and stopped allowing access to her printer from anything but her machine. Since I have two other printers, I haven't spent a long time looking at it. Her machine can see my shared printer though.

However, I had a weirder problem pop up 2 days ago. Suddenly, my machine ceased being able to use the Wireless (802.11b) network. Very odd. I have a 100 mb wired LAN, so it wasn't a crisis; damned inconvenient though. So today I sat down to look at it in depth. Windows had reset my wireless connection settings - once I restored them to the way they had been set, it all worked again.

This sort of oddness is very disturbing. ME was awful, and NT wasn't as stable - but I can't recall either OS ever spontaneously changing access settings on me. I have auto-updates from MS turned off - I have to approve everything that comes in - so it's not some service pack hosing me off. At this point, I have no idea what it is, and I find it very odd....

About this comment to my earlier post, there's a bit of a story there. The party we went to today was the 7th birthday party of our best friend's older daughter. The party went well, compared to one we through here for my daughter a few years back.

It was November, and pretty warm. We took the kids outside so they could burn some sugar off. They were playing tag, and one of the girls (who has three older brothers) got a little wild and shoved one of the smaller boys to the ground. We had the separate the two, and bring all the kids in.

That's when we discovered that the boy was missing. We called his parents, figuring he might have run home - just a half block away). No, but they panicked. We started looking in the woods, across the street, and in the house. We finally found the boy hiding in a closet....

Much relief (and embarrassment) all the way around. We got apology letters from both kids, but we always felt like we screwed it up....

But is the Smalltalk community ready for the world? I saw this post on some of the cool things about Python:

Subclassing the built in Python types is cool. We're subclassing dicts in PyBlosxom and it contributes greatly to the readability of the code

Python is catching on - and many of the things people like about it are (and have been) core parts of Smalltalk. Developers are ready to listen - we obviously have to respond better than we have been...

At Michael Lucas-Smith's request, the TypeLess plugin for BottomFeeder has been renamed - to BottomFeeder-TypeLess-Plugin. There's a new one as well - a Telnet client. It also looks like some dev time tools are being built into TypeLess - the VW internet console projects - BottomFeeder, TypeLess, ane Pongo - are picking up a head of steam!

Always a challenge when you go to a child's birthday party - how many toys will get lost (one so far, down the sink), how many fits will be pitched (one major one so far). Most of the kids left, and we can all settle down for some pizza...

Uche Ogbuji has doubts about the value of SOAP:

Jonathan Bartlett has a spot-on rant on why CORBA is still superior to SOAP. I think a lot of people know this, but fear to say it. Duncan Grisby, the lead developerof the superlative omniORB came to the tenth International Python Conference (IPC10) and was on a Web services panel. I think he came expecting to have to defend CORBA's honor and was surprised when just about all the panelists agreed with him that CORBA is better than SOAP in practice.

He wasn't done there; he posted later on SOAP vs. CORBA:

This is a more in-depth comparison of SOAP to CORBA than the rant I blogged earlier. It is quite sharply biased against SOAP (I've never been much swayed by "eeew XML is so verbose" arguments). But I think many of its points are fundamentally sound. Mike Olson also ran some SOAP/XML-RPC/CORBA performance tests on Python, with remarkable results.

Those benchmarks came out with SOAP being dramatically slower than CORBA. Not a big surprise; sending reams of uncompressed text over the wire - as opposed to a binary protocol - isn't going to be fast. But he wasn't done yet - read here as well:

Rem acu tetugit Paul Prescod. IOW, He nailed the point, as he so often does. I think the idea of merging header and body into a single document is the single biggest flaw in SOAP. Yes, SOAP section 5 (the RPC datatyping section) was probably the largest overall mistake in SOAP's evoution (as even heavyweight SOAP boosters have started admitting now), but it is far less fundamenal than SOAP's monolithic design.

We (Cincom Smalltalk) support SOAP well; it's got a bandwagon of support, and there's no way we can just tell developers to use CORBA instead. Still, Uche makes some very good points here - well worth considering if your technical options have not been closed off ahead of time....

I'm feeling pretty confident about the BottomFeeder code at this point - I think 2.8 is pretty much done. All I am waiting for now is the gold CD for VW 7.1 - when that happens, BottomFeeder 2.8 will be released

I've noticed that you can subscribe to Feedster queries as RSS Feeds. For instance, this query will produce all the BottomFeeder references found - as an RSS feed.

That has possibilities.

So much for a nice meal - my wife's car had a flat, so I got to spend quality time with the jack. Joy. The meeting went pretty well - the customer I was meeting with looks like they will be expanding their use of VisualWorks. Always a good sign when the decision makers stay in the meeting, and the meeting goes for 90 minutes. So now I'm catching up on the day's mail and feeds...

I am off visiting a customer in Washington, DC this afternoon. I'll have more to post later

After a power outage a few days ago, I forgot to restart the application that generates the feed. Dohhhh!

Spotted in comp.lang.smalltalk:

We're planning on going to Java because it seems to have a larger community right now and because we just don't have anyone left that can program in Smalltalk.

Before committing youself to this plan, I recommmend sizing Dome (I'm sure Reinout or Bruce could give you rounded figures on no. of classes, no. of methods, and no. of statement and cascade lines, if you are not set up to get them yourself). Then compute how long the Java rewrite will take you by assuming only a sane number of lines of code per day written by whoever does it. Check this by getting a rough estimate of how many years of effort wrote it in the first place (find someone who was on the project, ask them how long and average team size, thence fudge up a guestimate), then multiply by three (it's slower to program in Java) and divide by your 'porting is easier than writing' fudge factor.

The above should take you very little time (there's no point in getting very accurate numbers as software metrics is a very imprecise science). If the two figures that result are

• within even very rough hailing distance of each other
• both way over any realistic budget the rewrite could ever have

then I recommend you stop even thinking about it (and, even more important, stop even talking about it as it will just block more sensible solutions). Instead, devote your limited budget to specifying what changes you want and posting them on Dome's pages. Invite people to convert the requirements into XP tests, agree their tests with you (good Smalltalk XP tests are very readable even by non-Smalltalkers) and thence solve them. It might happen even if you offer no money. It will happen if you offer money. It will be much cheaper than the rewrite even if the latter were feasible.

I think you should provide a parcel load of your vw7.0nc port as the first thing.

Just my 0.02p. HTH.

Yours faithfully Niall Ross

That's as good a summary on this topic as I've ever seen, and I've written about this before.

The Fuzzy Blog has a nice post on BottomFeeder's support for Feedster this morning.

I had sent Scott an email, and got back a very nice response. I had only just added this support into the 2.8 dev stream, so I went ahead and posted a 2.7 patch last night that adds this to the shipping version. Bf should pick it right up; if not, here's a download link.