Aria Templates CDN

[jakub-g]

Mind dump:

- IE 7 not supported? // ok just kidding
- maybe there should be a link to this forum < http://ariatemplates.com/forum/showthread.php?tid=94 > at the bottom, to report issues, ask questions etc
- since there's a "skin" URL param, shall we add "flatskin" or sth too? (question: what if someone requests AT-1.4.veryold with flatskin - either a big red error, or just serve the atskin?)

Edit: just noticed:

Quote:root:
to set a specific rootMap (i.e. the URL root used to resolve classpaths) which by default is the root of your webapp.

should be rootFolderPath - it's a path string, not a map

[Olaf]

Homepage updated (disclaimer + contact) and support for flatskin added. The latter serves the regular atskin if the requested version is below 1.4.12; if you feel it should send an error instead, let me know.

[jakub-g]

I've been trying to release lightweight Fiddler rules targeting cdn.ariatemplates.com and realized a couple of things regarding CDN while working on this. The most important is the following:

When someone requests a dev file, say:
http://cdn.ariatemplates.com/at1.4-12.js?dev
he gets a pre-built version, i.e. all of the bootstrap files are preprocessed on our side and squashed into a huge file which has nearly 15k lines (yeah not that bad compared to 22KLOC in Aria JSP). The remaining files are served on-demand in the old-fashioned way.

Compare this to the old good bootstrap-via-injection:
http://aria/aria-templates-old/1.4-12/dev/aria/aria-templates-1.4-12.js

While the concatenation is nice for speed (1 big request instead of dozens of smalls), and probably JS execution time too, it hurts debuggability, because half of the things you'll see will come from 'at148.js' in the stack traces.

Also, say I want to put a breakpoint in "DownloadMgr", I am unable to CTRL-O in the dev tools to find it quickly, because DownloadMgr will not be a separate entity (since it's been concatenated into the bootstrap). So whole lot of entries (see attachment) will be unavailable in Firebug's list (same in Chrome devtools), and the only way to put a breakpoint there would be to open bootstrap and look for the interesting line within this monstrous 15 KLOC file.

Since the reason for the dev mode is mainly to debug stuff, I think it's crucial to have the niceties I mentioned.

One option to achieve this would be to change the way we serve dev files. However as I mentioned, the one-by-one mode is slow, so alternatively we may have three modes min, dev, and devdev But I think it should be probably enough to change "dev" to serve src files instead of the ones from bootstrap build.

[jakub-g]

Some other issues (mostly about internals of the CDN):

1) Seems that for non-dev versions, we just have a big folder with all the versions thrown there, relying on MD5s for uniqueness: e.g.
http://cdn.ariatemplates.com/aria/pack-t...10c7641.js

I think it would be cleaner to have nice URLs like
/dev/1.x.x/...
/min/1.x.x/...
(or the opposite, 1.x.x/dev/... and 1.x.x/min/...)
and just call sth like

aria.core.DownloadMgr.updateRootMap({'aria':'http://cdn.ariatemplates.com/min/1.4.2/'}

in non-dev versions in the same way it's done for ?dev.

I'm thinking in terms of Fiddler rules, so we can have simple rules based on the nice URL structures on the servers, instead of different rules code for dev and non-dev. Also, ideally whatever we're doing with the CDN should resemble what's already in place for http://aria/aria-templates-old so we can easily reuse the rules' code instead of duplicating it. It's been painful enough to have 'ariatemplates.js' / 'aria-templates.js' etc. Consistency über alles

2) contrary to http://aria/aria-templates-old/ the CDN doesn't support directory listing, hence I can't traverse the folders to find out about directory structure. Not sure if this is deliberate or just overlooked. I prefer to have dir listing enabled so that in case something goes wrong I can debug things on my own rather than seeing 404s and wondering what's going on.

Also, since the index page of the CDN.AT.com is the informational page, you can't traverse the list of available versions (you only have a JSON with min and max version, but you won't see if patch versions are available etc.). If we moved things into the subfolder, say http://cdn.ariatemplates.com/at/ we might then make this folder listable too (i.e. I'd like http://cdn.ariatemplates.com/at/ behave like http://aria/aria-templates-old/ ).

[Olaf]

We could modify the directory structure of the non-dev folders but it is also used by other parts of the site, not only the cdn so... maybe in the future if time permits.

Other than that, all versions of AT between min and max are there, including the patched ones (which, remember, are only for internal purposes.) I'm not sure how having directory listing would help debugging? Can you elaborate on this?

[jakub-g]

Ad. dir listing: I meant meta-debugging/reverse-engineering the CDN I couldn't find certain files there until I've realized the 'dev' is actually 'lightly-packaged' version instead of pure src. Not that important for now.

[Olaf]

The following changes have been committed:
- directory browsing: /aria, /dev and /css can be browsed (using the default pages provided by Connect)
- nocors parameter to force CORS bypass (this uses the xdomain library we force for IE8&9)
- no more preflight requests (see https://github.com/ariatemplates/cdn.ari.../issues/1)

[Olaf]

(2 December 2013 14:56)jakub-g Wrote:  When someone requests a dev file, say:
http://cdn.ariatemplates.com/at1.4-12.js?dev
he gets a pre-built version, i.e. all of the bootstrap files are preprocessed on our side and squashed into a huge file which has nearly 15k lines (yeah not that bad compared to 22KLOC in Aria JSP). The remaining files are served on-demand in the old-fashioned way.

Yes, that's the way the OS version is built. You still have access to your "old-fashioned" bootstrap if you request the non-OS version.

[ableme]

Does it work with page engine?

[Olaf]

Minus the cdn restriction (so no IE7 basically), yes it does!