I got an excellent email from Ruud Steltenpool offering another perspective regarding the current state, and future, of SVG. I think this topic deserves a balanced treatment, as many of the readers here are only partially aware of what SVG is or how it applies. With Ruud's permission, I've included the exchange below (this was just casual banter between us, so manage expectations of perfect grammar and structure accordingly. The email starts at the newest message, going back through my reply, to Ruud's original email).   

---

-----Original Message-----
From: Ruud Steltenpool [mailto:svg @ steltenpower.com]
Sent: September 15, 2005 7:01 PM
To: Dennis Forbes
Subject: RE: SVG is Dead! Story at 11!

Thanks for the reply Dennis, (just call me Ruud) and a very good day to you too.

Go ahead posting, even though i found some things that could've been written  a tad more elegantly and some typos, i don't think it really needs changing.
And here are a few more somewhat loose bits:

The executive summary is very much about money.
SVG is about freedom of creativity...... , [[[[[sidestep example: SVG is a great way for 'coders' and 'clickers' to cooperate. A 'clicker' just hits "save as SVG" in their own favorite graphical tool and generates something a coder can easily work with in their own favorite editor. Some coders can actually think of things that look good, but can't handle a pen/brush/mouse and some are amazingly good at realizing the idea through coding instead]]]]]] ............... which makes SVG a tough sell.
It's related to that not many people know/understand/believe that you can actually make money (some companies are making loads of money actually) with free software. My attempt at grasping it http://steltenpower.com/OS4entrepreneurs.pdf

Nobody really puts a marketing budget behind SVG (yet), cause nobody owns it, nobody directly makes money off selling SVG. So no millions of dollars making sure we all hear about every 'superduper fantastic major' product the technology is used in. Perception is indeed important. Many people for example think that anything that moves in a website is Flash. Some of those just blindly clicked "Accept" once and are watching SVG instead some of the time. And with all major browsers except for IE doing some or a lot of SVG out-of-the-box now or very soon, there will be a lot more people thinking Flash while looking at SVG. Things are changing though, for
example: Though many brands are offering phones with SVG pre-installed, only just recently Sony Ericsson was the first to decide to actually mention it to their customers in the description of the many models.

Good thing you mention Google. I've used it extensively for anything related to SVG. And in the last year and a half a lot has changed on the web. First you would find a lot of the 'SVG is perfect for everything and will change the world tomorrow, starting with bringing world peace' kind of articles written years ago. Though these articles are still there they are a minority now. What i keep finding is articles on a very broad spectrum of subjects, with somewhere between the lines saying SVG.
Sometimes with "(Scalable Vector Graphics)", but usually nothing more than those 3 letters, no explanation, nothing. I think that really says a lot, it's used as nothing special, as the natural way to go.
And more specifically on Google, they used to not index SVG-files: now they do. And the Open Clip Art Library probably gets a lot more traffic since. On Google Maps: Jim Ley just showed on svg.org how to get SVG in Google Maps.
Google might just add SVG, probably silently. Maybe a bit after Mozilla
1.5 final (it's in beta now), or what about the mobile market, that is more bandwidth-limited ?

And on raster images being good enough: Often they just are, nothing wrong with that. SVG can and will also be used for things that are just plain annoying, the things we have Flash-blocking extensions for. And of course some of those rasters are already being created with SVG and if based on browser-sniffing they are partly replaced with the original vectors not many people will immediately notice it.

SVG sneaks up on you, no big bang, no explosion, though the hype years ago tried to make us believe so.

I'm not so sure of Adobe moving away from SVG. Microsoft will definitely try some usurping (don't forget many, many people use ancient versions of Windows, so don't expect to see things changing fast on that end. Just as with SVG, things just take time), but will have a hard time, even more when Adobe turns up a plug-in that does SVG+Flash+PDF tomorrow :-)

As you would like to have this 'discussion' appearing on the web, get yourself some more traffic with posting a link at svg.org

Regards,

Ruud

On Thu, September 15, 2005, Dennis Forbes said:
A very good day to you Mr. Steltenpool! Thank you very much for the
feedback
- it is very much appreciated.

Firstly, let me say that I love SVG - I think it is an elegant,
extraordinarily powerful, vendor-neutral solution. When I write about
my perception of its demise (or continued irrelevance), I don't do it
out of malice or dislike of SVG, but rather sadness at the way things
have turned out. I think SVG is one of the most underrated technologies out there.

Outside of that, my work schedule and focus has definitely been in
places other than SVG for the past while, so the truth is that I'm not
entirely attuned to all of the happenings in the SVG world. Instead
I've been watching the "Executive Summary" version of the happenings
in the SVG world.
E.g. while there are lots of small progressions and improvements in
the world of SVG, from outside looking in, it is a technology that
completely stalled. I absolutely believed that SVG should have
EXPLODED into the marketplace years ago, enabling a whole new
generation of dynamic and gorgeous interactive web elements, but
instead here we are today with an SVG use and saturation largely where
it was (or declined) three or four years ago. The market is seldom
rational, and it looks like most developers (who are the ones who
would drive this sort of technology) saw Flash, or even raster
graphics, as "good enough". I completely expected the open source
community to go nuts over SVG, and to embrace and adopt it
pervasively, but instead the SVG fork of Firefox (I've been trying it
on occasion for a couple of years) has been maintained and embraced by
just a couple of people, and many in the open source community simply
have a "bah, Flash is good enough" attitude. Now that Adobe is
inevitably going to continue to turn away from SVG, and Microsoft is
going to usurp the vector graphics community with their offerings, I
think the window for SVG to make a bang has passed.

I entirely agree that the flash specification in no way equals the
openness of SVG, and the restrictive clauses are onerous, however my
point was that it is "good enough" for many developers. Already when
advocating SVG I've been met with retorts that the Macromedia spec is
"open" as well.
Perception
matters more than reality, and the perception is that Flash is now an
"open"
standard.

At this point, the only way I can imagine SVG really making a serious
impact in the marketplace, and to become a general technology, is if
Google adopts it. If Google Maps, for instance, used SVG as the
underlying technology, it could catapult the technology. That's pretty
speculative, though, and I don't think Joe WebDev can rely upon that
when deciding on technical platforms.

BTW: Do you mind if I post your comment to me, and my reply to you? In
fact if you reply to this with corrections and clarifications, I will
post the thread from your reply on, giving you the last word.

Thanks and have a very good day

Dennis W. Forbes

-----Original Message-----
From: Ruud Steltenpool [mailto:svg @ steltenpower.com]
To: dforbes@yafla.com
Subject: SVG is Dead! Story at 11!

Dear Dennis,

On http://www.yafla.com/dforbes/2005/09/13.html :

I read an article on your website with the same title as this e-mail.
I'm not sure what you mean with "Story at 11!" (maybe cause i'm not a
native english speaker), but my best guess is "11 a clock" where 12 a
clock means really the end of SVG and my second best guess is that
it's some sort of expression meaning that you're joking.

Cause it is somewhat funny that your article shows up almost exactly
at the same moment as yet another big and important step in spreading
SVG even more. I am typing this in webmail from my Mozilla Firefox
with standard native SVG rendering, that was released just days ago.

It sounds like you're not very aware of how much SVG is being used in
the world. Some of your remarks are at least inaccurate:

Batik just introduced sXBL implementation (just after your article
though)

Flash is not as ubiquitous as MacroMedia likes to make us believe.
I believe it's on a lot of desktops, and i believe a lot more (than
SVG) BROWSERS are equipped to play Flash through a plug-in, but i
don't believe these numbers. "Lies, damn lies, statistics" And SVG is
used in lot more
places: big applications using it through Batik or other toolkits, KDE
using it for icong and wallpapers, Inkscape, the OpenClipArtLibrary
and Scribus getting more popular by the day for a reason.

Didn't you see that the Flash File Format comes with a restricting
license?

And on Adobe, well Kurt Cagle blogged on that very nicely:
http://www.understandingxml.com/archives/2005/08/on_adobe_svg_an.html

The mobile market is huge and compared to SVG, the use of Flash is quite
.. ehm..  Tiny :-)   Even though MacroMedia might be screaming all sorts
of things of the roofs (i don't know if that is a real expression in
english), i see more and more SVG phones showing up, really in the
hands of people, and services of for example Vodafone, the biggest
provider in the world, using the functionality.

Microsoft will indeed keep capturing something for quite a while, but
someday they have to start indeed capturing hearts, cause people are
starting to only spend money on things they fully like (and combining
with other tools is just too great a feature to miss).

And on the server, there we'll be running XAML to SVG transformations.

It's just the "open" movenment, a big force of cooperation, that
MacroMedia , Microsoft or whatever company cannot stop. They're
welcome to join though
:-)

Anyhow, i hope you're happy to hear this good news on SVG. Your
article managed to get me away from coding some SVG actually :-) That
will have to wait till tomorrow cause i'm falling asleep.

Maybe see you at SVG Open 2006? I'll buy you a drink

Ruud Steltenpool
organizer of a well-attended, fruitful and fun SVG Open 2005

The title of this entry is intended to be a bit controversial.

Controversy is required, as one of the thing that I've noticed in this industry over the years - especially as it tries to shape up and professionalize to combat offshoring - is the large number of otherwise brilliant people desperately clinging to whatever looks like best practices. Traditionally they would be called cargo cultists, but I don't think that really applies, as they don't really expect the planes and ships to drop off cargo (that only makes sense in the context of the linked analogy, which details a South Pacific tribe that, after seeing allied forces receive wonderful cargo from ships and planes, thought that dressing up and acting like the allied forces did, with straw runways and bamboo earphones, would magically make plane and boat loads of cargo appear for them as well. They thought that the process they observed was the important part, and the cargo was a secondary effect of it. I love that story as it is exemplified in so many areas of human behaviour).

Instead they simply want to look the part to the greatest degree possible, doing a good job where they can, but ensuring that no-one can question their decisions because they've deferred all rational judgment to the beating mantras of "industry best-practices". Patterns, code-reuse, frameworks, struts and MVCs, CRUD, n-tier, web services, process, and so on. I'm hardly the first to observe it, but in a couple of very large corporations I've watched whole divisions pursue efforts that everyone (and I mean everyone) knew would be detrimental in every way that they were supposed to help, but people were happy as long as it covered their behinds in the case of questions from higher up. This isn't just a culture of yes-people, but rather one where people will happily pursue activities that give the illusion of best practices, without ever questioning or understanding why it's a best practice, or whether it's really a best practice in their unique environment or niche.

One such "best practice" (there are many that I'm suspicious of, but I should probably keep this entry at least remotely focused) is the tendency of teams to accumulate, and advocate the reuse of, internal code. This is often done under the banner of frameworks, common libraries, component sets, and so on. The idea is that with this accumulated quantity of code, each new project will have a leg-up on the competition. Code in the library is considered an asset, and managers and owners like the idea that, while developing product A, as a side effect they're accumulating this great repository of generalized code which they'll be able to use for a completely different product - let's call it product B. Soon the domain knowledge of their developers won't matter (and thus they'll be expendable), because everything is encapsulated in common code: They've codified the abilities of their team.

This couldn't be further from the truth.

The greater the bulk of code you accumulate, the more intrinsically you tie yourself to your current developers (and the more they occupy their brain with information that is only applicable in one organization or team), and the more difficult it will be to bring new developers online. Such frameworks and libraries often come with enormous learning curves for new hires - especially as documentation is virtually always ignored - and they can seldom be reused for anything else without significant refactoring (because they likely weren't truly designed for reuse, or they were in only the most arbitrary and superficial of ways. I think every developer can empathize with being told that they could "just use our library X to do that", to find that it offers nothing remotely like the promised functionality, so the developer is then tasked with not only building the functionality, but building this single-use functionality in a manner consistent and generalized for the library, despite it being unlikely to serve any purpose for anyone else, ever).

The question every organization needs to ask itself, then, is what value they could sell their "reusable code" for - what, realistically, would competitors and new entrants in the field offer for it? The answer, in almost every case, is $0, and they wouldn't want it even at that price. There is extraordinarily little code theft in this industry (even though we're in the era of burnable DVDs and USB keys) because most code - above and beyond the industry-wide frameworks and libraries - has no value at all outside of a specific project with a specific group of developers. Trying to use it for other projects is often worse than starting with nothing at all.

Perhaps I'll augment these thoughts, and refine them further, in the near future, but a couple of bullet points should convey the basic premise.

• The statement "I believe in code reuse" is nonsensical. We all believe in code reuse, where appropriate, but it isn't an all encompassing mantra. It doesn't make you a better developer beating your chest with empty statements about code reuse
  
• Code reuse doesn't happen by accident, or as an incidental - reusable code is designed and developed to be generalized reusable code. Code reuse as a by-product of project development, usually the way organizations attempt to pursue it,  is almost always detrimental to both the project and anyone tasked with reusing the code in the future
  
• Internal code reuse for niche industries and domain specific problems can be very valuable, but code for generalized, industry-wide problems are seldom valuable unless you're truly developing it for industry-wide consumption (e.g. the .NET Framework is tremendously valuable code reuse). I have seen too many examples of large internal libraries that are largely duplications of vastly superior functionality existing in the .NET Framework or C++ Standard Template Library, or which could be better served by available professional or open source libraries. If your problem isn't domain or niche specific, but rather is industry wide, it is extremely likely that either a library encompassing it exists, or that it isn't a problem that is worthwhile generalizing
  
• Always reasses your internal code, and continually compare it against what is available in the field. For instance if you've abstracted some data access, maybe you should look at the Microsoft Data Application Blocks (there are countless developers who know this framework, and it has been heavily vetted, versus a couple of developers internally hacking out their own data framework). Perhaps you can replace your internal encryption library with something that is industry wide. The goal should always be to minimize the amount of code in internal libraries to that which truly gives a strategic or tactical advantage, leveraging the talents (and agility) of the industry to the greatest extent possible.

In the end there are some wonderful examples of brilliant code reuse out there, but there are also a lot of terrible, horrific, productivity destroying monstrosities. How many projects have been led awry when the first task, before the product is even understand or any sort of requirements gathered, is the ever nebulous "build a framework" task...

I decided to hash together a quick and simple survey component for this blog (to be released publicly as open source as well). While the data access is via interfaces and dynamically instantiated helper classes, and thus data source agnostic, the first concrete class I decided to make was one that uses Microsoft Access as the back-end data store. For low-end uses like this the performance of MS Access/JET can be more than adequate (the non-transactional performance can actually be superior to SQL Server in some scenarios). Using the OLEDB ADO.NET components made pretty quick work of it, and it is refreshing to go back to such a simple, file-based data store, versus the SQL Server and DB2 architectures that I've been using for the past couple of years.

Just to validate that Access could offer the desired low resource usage, along with the capacity to handle the odd spikes in volume, one of the first tasks was a quick benchmark to test my data methods. I was shocked to see how slow they were. As a bit of background, I always strive for minimal resource usage, using features such as dispose patterns (keeping connections, commands, and other resources active for the minimal amount of time), relying upon the connection pooling of the underlying data providers to decide when it was appropriate to tear-down connections. This is critical in web apps and web services.

Anyways, long story short - Access, and the other OLEDB->ODBC data providers, do not by default enable connection pooling. What this means is that each time my method was hit it would reopen the file, reorient itself, get the data, close and release the file, all to repeat it again on the next iteration. This is absolutely terrible for scalability, which I saw demonstrated in my little test.

What I discovered (and this is old hat for Access developers, obviously) is that you need to add OLE DB Services=-1 to your connection string. With this directive, OLEDB turns on connection pooling. The results in my test were overwhelming, and the performance increased dramatically. This is obviously old hat for people who regularly target Access, but for the Access part timer it is probably a thief stealing their performance.

After the laborious process of uninstalling all of a prior .NET 2.0 beta, and then installing SQL Server 2005 on one of my dev machines, now the Visual Studio 2003 install (which of course utilizes .NET 1.1) is spitting up with an automation error, refusing to run. So now I'm stuck with repairing that install, unsure what exactly is causing the issue (I didn't install Reporting Services, so why this impacted Visual Studio 2003 is a mystery to me). [UPDATE: A repair did nothing, and there are no google hits that describe the same symptom, so now it's a full uninstall and reinstall. A quick project I wanted to bang off in the small amount of time available has already had most of the available time eaten by this sort of issue]

I appreciate that I should try betas on virtual machines, and often I do, but maintaining and configuring virtual machines is a time consuming process, and for some installs I expect there to be some level of side-by-side capabilities. I never had a problem with any of the prior betas of VS.NET 2005, or SQL Server 2005, so who knows.

As, err, "regular readers" know, I just started this blog a week and a half ago. Since then I'm up to around 400 visitors a day in here, which I'm pretty satisfied with given the limited amount of content thus far (though I think it's pretty good for a week and a half! Apart from a couple of dedicated, focused efforts, most of this has been off the cuff commentary, but it really adds up quickly. I could imagine the corpus of info that will exist here in a year).

Nonetheless, I would like more traffic, to the point that I'm saying "Scoble? Who's that?".

One of the ways to drive traffic to a site is through the use of Trackbacks. This mechanism, at its root, is a quid pro quo arrangement between blogs - e.g. I post a brief summary of something a "big" blogger said, and then ping their site with a trackback. They post the trackback link and users, and search engines (and PageRank if nofollows isn't put into force), go both ways. You pat my back, I'll pat yours. As mentioned in a prior posting, I currently don't have trackbacks or comments because of the slowness of the Radio Userland servers, not to mention that it would be a hassle to monitor it for spamming. I investigated implementing my own trackback server (it's a very simple spec), but the current industry belief seems to be that trackbacks are dead because of spam (which is a funny claim, because trackbacks are pretty much by design a type of targetted spam).

So for the meantime I am going to continue to monitor referral logs, as I always have, and if I notice someone coming from a link or post on your site, and I can validate that it's real, then I'll add a note on the posting. Basically it's a manual trackback system.

Over the past couple of days there has been a lot of discussion regarding some new, higher density flash memory devices. While I don't think a doubling of density is all that remarkable or technology shifting (flash is still quite slow compared to a modern hard drive. This isn't to discount it, and there are a tremendous number of very valuable uses for such a solid-state, low-power technology, but just wanted to mention that it isn't a panacea and there are compromises), what fascinates me most about these sorts of discussions is the metrics articles use to help people understand capacity. The article linked above states that "By combining 16 of these, manufacturers get 32 Gb[GB - sic] of flash memory that can store more than 32 hours of HD video files, 8,000 digital music files (670 hours), or 200 years of daily papers.". Woo, 200 years of daily papers (all papers? One paper?). Remember when the standard metric was the number of copies of the King James Bible? I never knew how much space the Bible would actually require, but it sounded like a lot when something could hold multiple copies of it.   [UPDATE: Looks like it's about 4.8MB uncompressed, so a 32GB flash card could hold 6,826 copies. Sounds impressive. But how many "Libraries of Congress" could it hold?].

As flash memory starts to compete with hard drives, operating systems will need to mildly adapt. For instance, flash has a limited lifespan, with localized degradation each time you erase a block: The common behaviour for operating systems to page out blocks of memory to the storage system unnecessarily, such that Windows does regularly, and to endlessly create and destroy small temporary files on the filesystem. Either wouldn't be a wise thing to do with flash. It will be a good thing as operating systems adapt, as I'd love for my hard drive to actually power down when I'm not doing something that actually requires its involvement.

At the beginning of the year I published parts I and II of the SQL Server High Performance Series, promising Part III "soon". This series was very well received, and garnered some great feedback and encouragement, but then I got overloaded with other things (primarily the birth of my second child - my son Weston).  

Well I have finally dedicated a bit of time, and plan on wrapping the series up over the next two weeks. While it isn't the most indepth or profound guide on designing for performance, it does contain tips and tricks that experience has shown me most database implementers (most of whom are part-time database designers by necessity) don't know.