>> Looking at the protocol-level implementation, I'm guessing you can't 
>> include newline characters in an object key. ;-)
> 
> You might be able to if you encode them appropriately, as %0A for example.

Ah. So the keys are URL-encoded?

>> Yeah, you can do it with offline processing. But I found that when I 
>> did it that way, I almost *never* posted any blog entries. It was just 
>> too much effort to add a source file, run the processing tool, run a 
>> seperate tool that zips up the changed files, log in to my host, 
>> upload the zip file, unzip it over the WWWroot folder...
> 
> Insufficient automation. It should be one click.

How do you log into a website and click some JavaScript-powered buttons 
from a script?

Besides, even then, I can only update the blog from the one PC that has 
the source code and all the automation scripts installed.

>> Currently I have a real blog interface. I can update my blog from any 
>> PC, anywhere on the Internet, without any special tools. The only 
>> problem is that it's 100% non-compliant as far as standards go. Oh, 
>> and buggy as hell! (It keeps "eating" my formatting instructions... 
>> and the CSS eats bullets.)
> 
> ... and that it requires you to run a real server. ;-)

Well, no, I got it for free as part of my web hosting package. But if I 
wanted to change to a different blog engine (say, one that doesn't SUCK 
as much), I'd have to pay £15/month for a virtual server instead. (And 
configure Apache by hand - which is pretty hard.)

>> Er, yeah. This is the problem part. It is almost impossible to get any 
>> SMTP server on earth to accept inbound SMTP messages. I've tried.
> 
> Um, no, it's not *that* hard, assuming you're subscribed to the ISP.

Well, I've never got it to work, let's put it that way.

>> How about S3 though? From the looks of it, I can set up my own AWS 
>> account, and then I can upload content. But what if you have a team of 
>> devs producing content that you want to upload? Do you really have to 
>> give them all the root password to do that? 
> 
> You can give them write permission to the bucket on a user-by-user 
> basis. They'll still need some sort of AWS key, tho, yes.

Right. So there *is* a capability to set up multiple user accounts in 
AWS then? (Which is what I was trying to get at.)

>> Oh *God*, I've lost track of which transfers are free and which ones 
>> get charged at both friggin' ends. E.g., traffic from SQS to EC2 US is 
>> free, but from SQS to EC2 EU is chargable one-way.
> 
> Probably because SQS is hosted in the USA. :-)

Well yeah, but you see my point. Figuring out what is and isn't free is 
a complex minefield. The pricing structure is so complicated...

Post a reply to this message