frekw

As far as I know, Nordic Edge (http://nordicedge.com/) provides solutions to quite easily make your SaaS app SAML enabled to login via a remote AD/IDP, but all their products are proprietary.

You only get invites is you have a premium account (2-3/month if I recall correctly).

Some invitations:

cFYRnaVgfcBYcHH4

fBMLspgTF7BHcRG2

apR5Pfyq8wPzpfTB

akeAbUJG2rLegCVR

bXsqWk2X8CdE3u8q

cJe98FeBPxbFKZq8

drp8Z28F9CRPppgb

eS246SkKmR7BkHmc

aaAwWd8wDpLtbyK8

dhumPYKa39FpheNt

eeZ7kDbS627tZWT3

fDrYCerDMxTwhcwR

aur28tHeccFFkwmd

dS4BNB6sRfkHXLdT

bWL8EA3gykcKJ297

ee4bT9x7hqnwYn6Y

bpm37X3WRJzbetYP

a5BC5M9Wc7DqHTBt

dZBuu2N822TsFnuV

ayXFyz2UpkTt8nxP

bxgLmUd9St9TDZyE

cT84HV9bNDKBTzFB

d2HP73bXDeFzXJ6m

c2DdHmFHTFPndmbz

cK7p6Bb2km9gs9ys

dEkcKKAbqgKrqDSg

fhEphBnfdVDMbFMg

fJLy43hTBdAry8rW

Enjoy!

It's a bit ironic that Amazon WS has become a SPoF for half the internet.

Yeah, I'm aware of that, but from my experience the code can end up uglier than it needs to be, either because you need to pass through proxying views further down the chain, or need to duplicate functionality.

I guess I just dislike the convention of interacting directly with collections from places where it shouldn't be done, e.g a todoView removing its own Todo from the collection (hence the risk of duplicating functionality throughout your code), instead of asking a proxying controller to do it. I think this is the reason as to why I've seen a lot of Backbone code where a reference in to the view is stored in the model itself (e.g http://documentcloud.github.com/backbone/docs/todos.html), which disgusts me since it completely misses the point of MVC.

Also, events passing feels more complicated than it would need to be (even if you can always include Backbone.Event).

I actually think that Spine seems to implement more sane controllers than Backbone (but I never really liked Backbone's way of doing it in the first place).

Controllers are supposed to coordinate the interactions between views and models by propagating changes and events between the two.

For example, if you had a todosController responsible for controlling a collection of views, there isn't really a clean way (in my opinion) to utilize it from two independent Backbone views without passing the controller through to the view (which makes the view depend on the controller). By handling events in the controller instead of in the view, you remove this dependency (which is also similar to my perception of Cocoa's delegates/SproutCore's bindings, but I may be wrong).

Both Spine's and Backbone's view layer consists of rendering templates to the DOM. To me, a "proper" view layer would include things like positioning and both frameworks seem to utilize CSS to do this, for the most part.

I think of Backbone's controllers as a poor man's State chart, without any enter or exit callbacks (e.g going from "#/" to "#/todos" should trigger a callback that states that I will exit the state "#/", so I can do necessary cleanup).

I don't understand your 3G argument. I use 3G to connect to the Internet from my desktop for various reasons, and I've used plenty of SC apps via that connection.

Isn't this really a problem solved by the HTML5 offline application cache?

Well, it utilizes WAI-ARIA for most (if not all) controls which is really all it can do.

The rest is up to the implementers of assistive technologies, in my opinion. If you want to be able to build rich, themeable interfaces you will end up having to re-implement "standard" controls like buttons, scrollbars and checkboxes. As far as I know, the ability to actually use native controls is actually being considered for SC 2.0 (read more here: http://groups.google.com/group/sproutcore-dev/browse_thread/...)