Web 0.0
brink
Web 1.0
blink
Web 2.0
link
Web 3.0
think
Categories
Category: Technology
Categories
Amazon S3 pricing
Amazon just sent a letter detailing price changes for the S3 service. They’re as follows:
Current bandwidth price (through May 31, 2007)
$0.20 / GB – uploaded
$0.20 / GB – downloadedNew bandwidth price (effective June 1, 2007)
$0.10 per GB – all data uploaded$0.18 per GB – first 10 TB / month data downloaded
$0.16 per GB – next 40 TB / month data downloaded
$0.13 per GB – data downloaded / month over 50 TB
Data transferred between Amazon S3 and Amazon EC2 will remain free of chargeNew request-based price (effective June 1, 2007)
$0.01 per 1,000 PUT or LIST requests
$0.01 per 10,000 GET and all other requests*
* No charge for delete requestsStorage will continue to be charged at $0.15 / GB-month used.
The reason for the change is also given in the email:
There are two primary costs associated with uploading and downloading files: the cost of the bandwidth itself, and the fixed cost of processing a request. Consistent with our cost-following pricing philosophy, we determined that the best solution for our customers, overall, is to equitably charge for the resources being used – and therefore disaggregate request costs from bandwidth costs.
As regards to who is going to be impacted the most, sites which host against S3 that have a lot of RESTful activity are going to be seeing new charges, and it will be interesting to see what happens in this regard. This change also encourages such sites to look at using EC2 for their processing, as well as S3 for their storage.
I don’t have detailed information about how many PUT and LIST requests I chalk up a month, but this will most likely impact positively on me–I should be paying less, because most of my bandwidth costs are associated with serving up the images, an activity which doesn’t use a PUT or a LIST. Hard to say, though.
This is the risk you take when you use a centralized service: changes in terms of service. This is the main reason I avoid it–that and issues of reliability. Chances are, it’s still cheaper to host at S3 rather than locally, but we’ll see. Again, though, I’m small peanuts to the service.
Categories
MIX
It’s difficult to miss what’s happening with MIX, there’s so much discussion about the announcements and technologies released.
Danny Ayers was able to discuss what he was shown on his recent trip to Microsoft: Astoria, a RESTful interface to data services through the web. The data can be returned as XML, JSON, or a subset of RDF/XML, which is a little surprising. I’ve not had much chance to look around–I hit ADO.NET and bounced back. I’ll have more on this later.
The second one was all things Silverlight. You would think that Microsoft invented, well, Flash. Mary Jo Foley covered the new Silverlight Streaming and quotes Ray Ozzie saying it …will let you post your media to the Microsoft storage service in the cloud. Posting to Microsoft’s centralized server is not ‘posting to the cloud’, from a distributed point of view.
I was more interested in the new Dynamic Language Runtime (DLR) and the cross-platform CLR, but I’m still trying to find the real bits from the marketing. Sure a lot of marketing folks at MIX. Why in all that is holy, was Michael Arrington interviewing Ray Ozzie? You need to sell to the developers Microsoft–you don’t need VC money. Sucking up to the wrong crowd. Oh, there we go.
Between MS and Adobe, Rich Internet Application developers (that’s ‘Ajax’ for you not in the know, do try to keep up with the changing terminology, or be marked as passè) will be inundated with a barrage of new tools in the next year. Competition is good for the developers…as long as you can survive the corporate love.
Recovered from the Wayback Machine.
Really nice writeup on the conflict between Microformats use of abbr with hCalendar and accessibility:
The datetime-design-pattern is a way to show a readable date (such as “March 12, 2007 at 5 PM, Central Standard Time”) to humans and a machine-readable date (such as the ISO 8601 formatted “20070312T1700-06”) to the Microformat parsers. When crossed with the abbr-design-pattern, the result is this.
<abbr class=”dtstart” title=”20070312T1700-06″>
March 12, 2007 at 5 PM, Central Standard Time
</abbr>As you may have guessed from the previous examples, screen readers expanding the abbreviation will try to read the title element. JAWS helpfully attempts to render numeric strings into human-readable numbers, so “1234” is spoken “one-thousand two-hundred thirty-four” instead of “one two three four.” Given a title value of “20070312T1700-06”, JAWS and Window Eyes both try to read an ISO date string never intended to assault human ears:
Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six. (JAWS 8 on IE7: MP3, Ogg)
I particularly liked this article because it provides details as to exactly how the concept in question is being rendered in screenreaders. You’re not left to guess, based on some vague, “Doesn’t work with screenreaders”. It really gives weight to the authors’, Bruce Lawson and James Craig, concerns.
I can’t figure out, though, why RDF always gets slammed whenever discussions of this nature arise:
Some have proposed using custom attribute namespaces for Microformat data, but the Microformats group is strongly opposed to this, and for a simple and valid reason. Microformats are intended to be “simple conventions for embedding semantic markup in human-readable documents.” Opening the floodgates to custom DTDs and namespaces would quickly raise the complexity level of Microformats to that of RDF, greatly reducing its adoption and therefore its relevance.
Here I was, tripping along on a well presented argument defining a tricky problem when, bammo: it could have been worse, it could have been RDF.
It’s as if RDF has become the bezoar stone of metadata–people invoke RDF to draw out all the evil.
“Ohmigod, an asteroid is going to hit the earth and we’re all going to die!”
“It could have been worse. It could have been RDF.”
“You’re right. Whew! I was really worried for a moment.”
First update
We’re going to be coming at you with …AAAAARRRRGGGGGHHHH!… custom DTDs! The horror!!!
Damn near stopped my heart with that one. You want to be more careful, Tom.
Second Update
Here is the first entry of the microformats discussion thread on this item. It gets quite interesting as the thread progresses.
I’m not making any editorial comment on the thread. Nope, not a word. Not a single word. I’m just going to sit back and play with my triples.
Categories
Ajax security: FUD or fact?
from_future_import has a post stating that Fortify’s recent Ajax alarm is more FUD than fact. Money quote in this one:
And MOST importantly the exploit is only applicable to JSON that also happens to be valid JavaScript code.
Was it FUD or fact? A bit of both. The benefit of the paper is the fact that unlike other discussions on these issues, it was written in plain English, diagrammed, and not meant to be understood only by insiders. Perhaps if more Ajax developers would adopt the same approach to documenting issues, concerns, and examples, documents such as that given out by Fortify wouldn’t get the audience.
Or we could all use XML, only (she says as she ducks and runs…)
While I was in the neighborhood, I picked up a couple of other links in comments:
Practical CSRF and JSON Security
An ArsTechnica post on the original article.
(Thanks to Michael Bernstein for link)