PDA

View Full Version : Hosting yui-ext and Ext



alexchoowk
23 Feb 2007, 9:55 PM
Hey,

Seeing how Yahoo is now hosting YUI for users, I wonder if I could contribute by doing the same by hosting yui-ext on Amazon's S3.

http://developer.yahoo.com/yui/articles/hosting/

Would like to hear what you folks think about this. Although I cannot guarantee that I will do this *forever*, you could still use it for development.

What do you think?

Alex

Bobafart
24 Feb 2007, 6:19 AM
I think that is a *great* idea (of course it isn't my decision to make) but I still think it would be awesome!

jack.slocum
24 Feb 2007, 6:26 AM
That would be great. Does Amazon allow it?

alexchoowk
24 Feb 2007, 7:48 AM
Jack,

Amazon S3 allows anyone to host almost anything you can think of. If you're ok with it, I will go ahead. The beauty of Amazon S3 is the high bandwidth that's available.

I do not intend to create a webpage to tell people about this link. Do you think you could inform people through your website or wiki? I'll just be responsible for hosting it. No intention of making a single cent off this. In fact, seeing how popular yui-ext is, I think it's gonna cost me a few cents in hosting fee each month :)

Is that ok with you?

jack.slocum
24 Feb 2007, 8:25 AM
When a build goes out if you could send me the urls, I will include the info in the release post. This will be great, thanks! Also, please let me know how you would like to be attributed. :)

One question, does amazon support caching headers or gzip?

alexchoowk
24 Feb 2007, 8:59 AM
Jack,

To my best knowledge, Amazon S3 is a storage system. So it doesn't do gzipping or caching. I'll not worry about this yet. Their charge is $0.20/GB of transfer, and I'll be happy to pay a few dollars in hosting cost as a way to contribute to your work.

I have uploaded versions 1.0alpha1 and 0.33 of yui-ext to S3.

I only uploaded the files in the root directory of your zip package, and everything in the 'build' and 'resources' subdirectories. If anyone wants to view the unminified source code and documentation and examples, they'll have to get the zip files from your site.

For version 0.33 the base url is http://s3.amazonaws.com/yui-ext/0.33/
For version 1.0 alpha1, the base url is http://s3.amazonaws.com/yui-ext/1.0alpha1/

Example of the directory structure:

To get the file yui-ext.js (located in the root directory of your zip package), the url is http://s3.amazonaws.com/yui-ext/0.33/yui-ext.js

To get /build/anim/Actor-min.js (as defined in your zip package), the url is http://s3.amazonaws.com/yui-ext/0.33/build/anim/Actor-min.js .. and so on.

I think you get the idea :)

Charles
24 Feb 2007, 3:30 PM
Since a bucket can be referenced with the Host part of the HTTP request, if we set up a bucket named something like "ext" so that things can be referenced at http://ext.s3.amazonaws.com. We could then make a DNS alias for Amazon S3 off of the new domain so that http://hosted.extjs.com/ references S3.

no gzipping is the biggest downside and at the moment, I can't think of a good solution there.

jack.slocum
24 Feb 2007, 5:24 PM
Very nice. .20 could add up with no gzip! If you can set up that "bucket" I will set up the DNS entry and start blogging. :)

alexchoowk
25 Feb 2007, 4:22 AM
http://docs.amazonwebservices.com/AmazonS3/2006-03-01/VirtualHosting.html

Hi,

Please see the above documentation. From that, I figure that I would need to create a bucket called hosted.extjs.com so that you could create the DNS alias.

Is Jack ok with that? I think extjs.com is his domain, and would prefer not to 'hijack it' ;). Does anyone know if it's really necessary that the bucket be called hosted.extjs.com?

By the way, I cannot guarantee that this free service will always be around. So you should not to embed those links for a production app.

Jack, if you have your own Amazon S3 account, it might be better for you to host it yourself as you always have the latest code. But I'm still more than happy to help out :)

Charles
25 Feb 2007, 10:20 AM
By the way, I cannot guarantee that this free service will always be around. So you should not to embed those links for a production app.

DNS entries could always be remapped or the Amazon account could be taken over -- perhaps creating a new S3 account (so that anything else you are doing isn't also tied to this) where billing information could be changed if hosting becomes burdensome and you have to pass the torch would be a solution.

Without gzip, the ability for S3 hosted applications to be used in production situations is limited... but what is the reality of production applications wanting to host this? My thoughts on the real value of hosted JS for EXT is in development and for use with examples. In those cases not having compression is the price to pay for being able to link against a remote build from the actual source.

alexchoowk
25 Feb 2007, 6:12 PM
Charles,

Your reasoning is spot on.

A DNS alias to S3 poses another potential point of failure, because the DNS service could fail temporarily for some reasons.

I'm all for doing whatever the community wants. As it is, s3.amazonaws.com/yui-ext works fine.

If you guys prefer hosted.extjs.com, then I will upload all the files to a new bucket with the same domain. If you want to do without the DNS alias and find yui-ext misleading, we could go for 'extjs' as in s3.amazonaws.com/extjs/

I've already reserved that bucket name :)

Just tell me what you want.

JeffHowden
25 Feb 2007, 6:38 PM
Gzipping with S3 isn't an option because Amazon doesn't do any sort of accepts content header content-type negotiation. So, any browser that doesn't support gzipped content won't be able to work with the gzipped files on S3. Clearly (in a production environment), that's a no go.

Charles
26 Feb 2007, 10:53 AM
Gzipping with S3 isn't an option because Amazon doesn't do any sort of accepts content header content-type negotiation. So, any browser that doesn't support gzipped content won't be able to work with the gzipped files on S3. Clearly (in a production environment), that's a no go.

I had thought of this... but I'm not aware of any browser that doesn't support gzip compression for HTTP and would support the functionality of EXT. It obviously wouldn't fail safe -- which may rule out production for some, but as far as limiting the user base, there are many things that "production" web aps do that would have a greater impact on limiting user base than this. At least that was the rationale that I was considering when I didn't immediately rule out the option... not to take away from the validity of your point, because I certainly don't disagree with it.

Charles
26 Feb 2007, 10:58 AM
Charles,

Your reasoning is spot on.

A DNS alias to S3 poses another potential point of failure, because the DNS service could fail temporarily for some reasons.

I'm all for doing whatever the community wants. As it is, s3.amazonaws.com/yui-ext works fine.

If you guys prefer hosted.extjs.com, then I will upload all the files to a new bucket with the same domain. If you want to do without the DNS alias and find yui-ext misleading, we could go for 'extjs' as in s3.amazonaws.com/extjs/

I've already reserved that bucket name :)

Just tell me what you want.

My biggest pro-alias argument would be that if S3 doesn't meet the needs of the community at some future point in time and another hosting opportunity presents itself, we can simply change the alias without breaking any examples or causing headaches for hosted users.

As far as DNS failure -- I suppose that is a possibility, but what is the probability of that happening? (I have no clue)

alexchoowk
26 Feb 2007, 6:57 PM
Charles,

Your point is an excellent one. I missed it completely, sorry.

I have created a bucket called hosted.extjs.com, and have uploaded version 0.33, 1.0alpha1 and alpha2 onto it.

Jack, you can try the DNS alias and tell me how it goes. If you need to email me, I am at alexchoowk at yahoo dot com dot sg.

With the alias, the base urls will be hosted.extjs.com/code/0.33/, hosted.extjs.com/code/1.0alpha1/ and hosted.extjs.com/code/1.0alpha2/

One thing though, the alpha code will not be up to date. Jack releases revisions very often, and I do not update as fast. Jack could you include a text file in your package to indicate the current revision number?

Alex

monteiro
28 Feb 2007, 3:20 AM
so what is the conclusion, i intend to use ext for a major project of mine

alexchoowk
28 Feb 2007, 8:50 AM
Ready to go, actually. the files are all up. Just waiting for Jack to get the DNS alias up and running, if he's agreeable to the whole idea.

Charles
28 Feb 2007, 10:39 AM
so what is the conclusion, i intend to use ext for a major project of mine

I think non-gzipped versions of the library will be available at URLs from hosted.extjs.com using Amazon's S3 hosting service. The community would then, I suppose, be welcome to link against those versions.

For a major project, most people would probably host their own. The real advantages here, as far as I can figure are examples (references to files won't be broken) and non-production applications (working with the latest version not requiring a download and subsequent upload to another server). I suppose there is also potential advantage to small groups and individuals who are doing proof-of-concept type work.

jack.slocum
28 Feb 2007, 11:02 AM
Hi guys. I am trying to set up the dns but my server is having problems (Go Daddy virtual dedicated). I have a ticket in with them. Sorry for the delay.

jack.slocum
28 Feb 2007, 11:35 AM
Ok, it's up and running. http://hosted.extjs.com/code/1.0alpha2/ext-all.js works!

It's a shame we can't use gzip.

Charles
28 Feb 2007, 2:12 PM
Ok, it's up and running. http://hosted.extjs.com/code/1.0alpha2/ext-all.js works!
It's a shame we can't use gzip.

That is actually really cool... (near) free hosting with a DNS alias. I've been meaning to do that for images for a while on my own projects (img1.example.com etc.), both to cut down on cost and to increase performance (I like MediaTemple, but I'm guessing Amazon has them beat on infrastructure... and HTTP requests across multiple authorities is a good performance booster regardless)

Actually, that is a point ... are images and CSS up on hosted? Even if I were using JS from my own site, that would be a nice hosting feature.

alexchoowk
28 Feb 2007, 8:48 PM
Thanks jack!

Erm, if the costs become unmanageable, can I take donations through your site too? ;)

alexchoowk
1 Mar 2007, 6:46 AM
Charles,

The directory structure within hosted.extjs.com/code/1.0alpha2 is similar to that which you can find in the zip file from Jack.

All the files from /, /resources, /package and /build are available.

/docs, /examples and /source are NOT included.

garyng
17 Mar 2007, 7:09 PM
Ok, it's up and running. http://hosted.extjs.com/code/1.0alpha2/ext-all.js works!

It's a shame we can't use gzip.

My understanding is that gzip content wth the proper Content-Type header can be served correctly from S3. So can it be done this way :

http://hosted.extjs.com/code/1.0/gzip/ext-all.js --for gzipped content Or
http://hosted.extjs.com/code/1.0/ext-all.js.gz --for gzipped contenthttp://hosted.extjs.com/code/1.0/ext-all.js --for plain text content

Since there must be an intermediate server in the picture(most of the time unless it is pure js hosting without server side processing), That server code can easily know if the client support gzip and change the javascript include on the fly to point to the right url for it(just a regex replace).

gzip IMO is important or the bandwidth cost can add up quickly if everyone use this instead of hosting their own.

The above link for example is 370K+ which I don't want to download. Think what happen if we have 1M hit at 0.2USD/G.

alexchoowk
19 Mar 2007, 6:45 AM
The total S3 bandwidth cost I've incurred from 1 Feb to today is 5 cents, so I'm still doing fine.

Browsers should automatically cache JS files.

I must stress that I'm offering this service out of goodwill as a way to contribute to Ext.

Please do not use this for production.