Hopefully this will be my last SimpleDB post for a while since I think I've spent way too much time on this(especially for a guy who should be laying off the blogging this week because he has way too much stuff to do already).  But I felt the need to quote this post from uncov.com.  It says...

One of the stupid parts about SimpleDB is XML. All of the query responses come back to the client as a blob of XML. Of course, as a blub coder, you don't see any of this because you are just using an API, so why should you care?

Let's have a gander at a typical query response from SimpleDB, provided in the developer documentation:

<QueryResponse xmlns="http://sdb.amazonaws.com/doc/2007-11-07"> <QueryResult> <ItemName>eID001</ItemName> <ItemName>eID002</ItemName> <ItemName>eID003</ItemName> </QueryResult> <ResponseMetadata> <RequestId>c74ef8c8-77ff-4d5e-b60b-097c77c1c266</RequestId> <BoxUsage>0.0000219907</BoxUsage> </ResponseMetadata> </QueryResponse>

 

Well, that's just fantastic. A 316-byte response when all you need is 18 bytes worth of data (the 3 unique identifiers). A 1,755% transmission overhead. And don't you give me shit about needing that RequestID, that is a consequence of the protocol.

Now that is a good point.  Looking over my last few posts on this topic I think I come across as a SimpleDB advocate but that isn't necessarily the case.  All I've been trying to say in my previous posts was that the criticisms should be fair.

Anything has advantages and drawback and that is more true of SimpleDB than it is of most things.  I'm all for putting the negatives out there as long as they're valid.  The above quote is just that which is why I wanted to put it out there.

So I'm back, brighter and earlier than I would have liked but I guess that was inevitable after 4 days away.  A few things that caught my eye over the (rather slow) weekend...

Sometimes I think everything in this world is controversial to someone.   Case in Point, Glenn Reid has an interesting post about XML where he says...

XML does not deserver its "ML", or even its "X". But first, the "ML" part.

I am one of the world's leading experts on markup languages. I'll start there. I'm a 20-year veteran of desktop publishing, am personally related to the author of one of the very first markup languages in the world (Scribe), and have actually used SGML, MML, HTML, and most of the other markup languages that came along decades before XML.

So I know what I'm talking about. XML is not a markup language.

Well, ok then.  I don't really know how to respond to that to be honest.  He may very well be right but (a) it really doesn't matter what you call something and (b) XML is easily the most widely adopted markup language in existence (if you count XHTML) so I would think that would be enough to change the definition (if we're brining it to a vote). 

Anyway...

In other news Scott Watermasysk of Telligent has a post asking "Are Trackbacks (still) Worth It?" and I have no real answer for him.  They do seem to be causing a lot of spam lately and though they're a good idea in theory I rarely see them used in any useful way.  That said, from his perspective and the maker of blogging/community software I don't think we're to the point where you can drop it from the feature list and expect everyone to accept that. 

Finally, on the "just kind of cool front",  Greg Dolley posted on how he converted Quake II to managed C++ in the latest version of Visual Studio.  It's a good post but the part I found most interesting was this...

On modern computer hardware and the commodity-priced video cards out there, it’s difficult to come up with speed comparisons between .NET versus native C++ when running Quake II. What I mean is this - pretty much all computers with a decent 3D video card run the game at its maximum frame rate anyway regardless of whether native or managed mode is used. However, I did see a difference in performance when I turned on just software rendering and used a high resolution. The speed differences weren’t that much - the .NET version was about 9% slower (94 FPS in native versus 85 FPS in managed).

However, non graphics related things, such as initializing the game and loading maps between levels were noticeably slower in the .NET version. I would wait about seven to ten seconds for the game to load in a managed build versus about two seconds in native mode. The same amount of slowdown was noticeable when switching between levels.

The truth is that very few people need the graphics power behind Quake II as it is so the fact that managed code is performing that well tells me that you are probably safe doing 99% of things in a managed environment.  If you are planning the next Halo on the PC you are probably better off with unmanaged code but if you're planning the next Halo in this day and age you probably aren't targeting the PC anyway.