I'm hoping we turn that Firebase fork into a pluggable interface for TogetherJS to exchange messages via other systems. Once that is in place I'm guessing Meteor would be simple too. Most of the Firebase support is in this one commit, and it's notably pretty small: https://github.com/firebase/togetherjs/commit/fdb11887c63342...
Speaking as the principal developer for TogetherJS:
In the past we have opted not to work on IE support because we had limited resources, and because we wanted to focus on what we thought were the hard problems: how should the tool act, how do we communicate changes between browsers, how do we integrate with apps, etc. Supporting Internet Explorer was always something we knew we could do, it wasn't a hard problem, but it still required some effort. As such it didn't feel like it was advancing the project. It was never meant as any slight towards IE, just an expedient way to save some time.
Also, while we do browser sniffing, we only use that to put up a warning for IE users to alert them that it's not going to work well. This was pointed out on Twitter as though we were actively blocking browsers, in part I think a knee-jerk reaction to browser sniffing, but what we've done still seems to me like a reasonable and responsible thing to do – better to admit you don't support a browser than just expose people to a crappy experience.
Of course times change, and as TogetherJS has become a more mature tool it's probably time to revisit our Internet Explorer support. But on the other hand this isn't a commercial tool, so I'm not entirely sure what resources we as a team will be able to invest in Internet Explorer support. But it's also open source, and we would welcome contributions to fix this. We'll be working on a slightly more structured plan soon. It might not even be much work, I really don't know.
One way a country could get to this would also be revenue-neutral taxes. A revenue-neutral carbon tax, for instance – a lot of taxes would be collected, on the theory of limiting output, or maybe you could use the theory that you were charging for access to the environmental load, which is a public resource held equally by all people. To make it revenue neutral then you have to return that tax money to people. You could cut taxes or put it some bullshit "lock box" but that's nonsense thinking. IMHO the only reasonable way to keep it truly revenue neutral is to directly funnel the money back to individuals. A basic income would be the result.
People freak out that a carbon tax would be regressive, and it would, but the return would be so progressive that it would more than undo that.
In general I think this kind of theory should be applied to more use taxes – places where ostensibly a tax supports something like roads, making a system self-supporting. But the use taxes only address a small part of the cost of roads, they don't consider the opportunity cost of using land for roads and they don't address the negative externalities. A use tax that included all of that, and returned some portion to people, would be a fairer tax. In that context something like congestion pricing would be fair in a way that it isn't currently.
I am disappointed when I hear the term "socio-economic factors" in discussions of education. First, as if "economic" wasn't enough you add in "socio" to create a term that means "factors coming from every part of a person's life". Of course there are socio-economic factors.
But I dislike it particularly because often it feels like a statement: we don't know what the causes are (which is why we make the weakest possible claim by using this incredibly expansive category), and we aren't going to try to find out.
So I particularly appreciate this program, and the research it is based upon. We have a pretty well identified phenomena: talking a lot to kids, at a young age, helps them. A lot. And some people talk to their kids a lot more than other people. We should delight in this finding! We have a pretty clear way to identify a lot of kids whose lives could be greatly improved through changes in their parents' behavior, and that change is widely accessible.
It's this kind of finding that penetrates "socio-economic factors" and in the process identifies something actionable.
Which means older people, who have generally been much less able to participate in startups at an early stage, can now have affordable insurance as individuals. Before not only could someone older (though not necessarily very old) be burdened by a high cost of insurance, but you could never be sure that your insurance wouldn't spike to some unrealistic amount. After a certain age insurance companies have been very willing to price a person out of the individual insurance pool (and force the person to move to government or employer insurance). Also god forbid you have a kid.
WebRTC makes it possible, but not easy, nor abstracted. You still have very long connection strings to establish the connection, and those strings change as you move around, so it's not something we'd want to ask users to send to each other in order to establish a connection. The approach usually used is a server where the two people rendezvous to exchange the connection strings. That server is kind of like what we have – but then once it's in place, changing over to WebRTC just doesn't seem as exciting. (And even then the connections are slower to establish and less reliable than WebSockets.)
[Team member here] We haven't been very focused on the hosting story, in part because lots of people have their own requirements, and we can't predict what they are. And maybe because predicting what they are is boring. I know some hooks for New Relic have been added to the server. It's also a super-simple server that only keeps things in memory, so it's pretty darn easy to handle. Just one file: https://github.com/mozilla/togetherjs/blob/develop/hub/serve... (and only one dependency, for WebSockets).
Both people are accessing the website as themselves. If one person doesn't have permission to see a page, for instance, then they won't see it. And yeah, whoever hits save is the saver ;) Doing something richer than that requires application-specific integration, which we want to support, but we also want to take cues from developers about what that should actually look like. This is one idea we have along these lines: https://github.com/mozilla/togetherjs/issues/372
On principle we keep the server simple, echoing messages back and forth between clients. In practice it's quite hard for two browsers to connect directly to each other, and while we want to support that kind of architecture in order to get it working we still need to simulate P2P using a server.
[Author here] The big way TogetherJS differs from many of the other realtime products out there, like Firebase or (to a lesser degree) ShareJS, is that it doesn't do any storage. It coordinates real-time sessions, but it's not there to take the place of the application, instead it augments the application. If your application has persistence, it has traditional persistence. Whatever auth system you have is your own. At the same time while it dodges any persistence, it extends the scope beyond what those other tools typically do to include more with session management and the standard tools that I think are needed for collaboration. There's nothing exciting about text chat, but you need it anyway.
Still, ignoring persistence I think will help keep the surface area of the TogetherJS smaller compared to some other tools. Or at least focused on other things.
People have mentioned the idea of being able to chop TogetherJS up before, but I have a hard time seeing how that would actually work. For instance, the architecture is built around a pretty dumb server, so hooking into Streams would seem counter to that principle. And just allowing for the possibility would add a lot of complexity. Ultimately the UI is actually the bulk of what makes up the TogetherJS code (or maybe it's the part I find hard and so I feel like I spend a lot of time with it), and I don't know how to make this kind of UI while being modular. Without the UI I don't think it's nearly as compelling a project (becomes more like ShareJS, or Firebase, or Google Drive Realtime API – neat but a big investment, and sometimes only appropriate for greenfield projects.
Anyway, I'm certainly interested in how people want to extend or integrate with TogetherJS. I'm skeptical of splitting it up into pieces, as it is theoretically easier to do things that way, but I expect in practice it will just leave a confusing pile of pieces that aren't fun to put back together. But that doesn't mean that there aren't use cases worth exploring... and with some creativity there might be other approaches to handling those cases.
IE10 has WebSockets: http://caniuse.com/websockets – but TogetherJS doesn't support IE10 either (simply haven't been able to keep up testing with IE in addition to other browsers).
If you sat down with her and did letter flashcards, she'd probably love that too. Probably love it more! Kids do not dislike the attention of adults. Schools often manage to both ignore and constrain the child. This is what rules are so good for: they allow for disinterested control.
The kids in my life are young at the moment, so I'm biased towards the experiences at those younger ages – and certainly more poisonous structures lurk as they get older. On the other hand, I'm not sure why you think I'm talking about school. The article is mostly not about school, and my reaction isn't about school, it's about the hours outside of school.
And no, preschools do not generally allow children to be physical with each other, and they tend towards rule-based conflict resolution instead of direct engagement, which are some of the specific examples I brought up.
Coincidentally I just came upon the term "Concerted Cultivation" (http://en.wikipedia.org/wiki/Concerted_cultivation) which describes the modern middle class typical parenting, the very thing that leaves kids with little time to play. Working back from that you get to the book Unequal Childhoods which contrasts middle class and working class parenting (http://en.wikipedia.org/wiki/Unequal_Childhoods#Parenting_St...). I find the contrast interesting:
"Concerted Cultivation: The parenting style, favored by middle-class families, in which parents encourage negotiation and discussion and the questioning of authority, and enroll their children in extensive organized activity participation. This style helps children in middle-class careers, teaches them to question people in authority, develops a large vocabulary, and makes them comfortable in discussions with people of authority. However, it gives the children a sense of entitlement.
"Achievement of Natural Growth: The parenting style, favored by working-class and lower-class families, in which parents issue directives to their children rather than negotiations, encourage the following and trusting of people in authority positions, and do not structure their children's daily activities, but rather let the children play on their own. This method has benefits that prepare the children for a job in the "working" or "poor-class" jobs, teaches the children to respect and take the advice of people in authority, and allows the children to become independent at a younger age."
----
When contrasted against Achievement of Natural Growth it's not so surprising that parents have decided to take another path. Simple romanticism about the past isn't really that helpful. Just kick the kid out of the house and let them play? People talk about the lack of peers that aren't similarly scheduled up, but I see kids all the time who are left free... and I'm not comfortable with how those kids are developing in that environment. Not that they aren't fine playmates, but it's not a kind of parenting I would want to imitate. And a lot of the efforts pushing for more structured time (more afterschool activities, full day kindergarten, universal preschool) are directed towards those kids that need it. But of course we all get washed up in it, even if increased structure is only needed by a segment of the population.
There are other models. Consider for instance Tools Of The Mind (http://www.toolsofthemind.org/), a preschool program that has shown surprising success. It incorporates a lot of pretend play, but adds structure to that pretend play. But it's not authoritarian structure. Adults are really important to children, we have a lot to offer. We can enhance play, get kids out of ruts, enhance the environment, help kids match up their desires with productive paths of learning. Which also means giving them independence at the right time. And sometimes at the wrong time. And sometimes kids need to be understimulated. But it's not that simple.
From the article: "You can’t teach creativity; all you can do is let it blossom. Little children, before they start school, are naturally creative." I don't buy that. Teaching creativity might be going a bit far, but it can absolutely be nurtured and inspired. Children, when just left alone, DO NOT DO WELL. I know just interjecting myself in a kids play for 30 seconds, at the right time, can considerably improve the creativity of their play. My nephew has been pretty into playing with blocks lately, but kind of repeating himself. I started making a bridge with a ramp, and he's been obsessed with those forms for the last few days, trying new configurations, larger structures, bridges across corners, all sorts of stuff. Real creativity, he's not just copying what I did. But he needed a little inspiration.
Do you just let kids work out all their problems between each other on their own? Sometimes kids work things out well. Sometimes they fight, often they bully, sometimes they are deliberately cruel, or depressingly meek. Setting up a bunch of rules is a bad solution too. Never hit! Now you can't play fight with paper towel rolls. And you can't learn how to interact physically without hurting each other. Always share! Or: always ask before taking! Or: turns! But sometimes one kid really wants something, and the other kid just happens to be holding that thing. Or sometimes a kid is just immitating, they ignored the toy until they saw someone else enjoying it. But the negotiated response is more sophisticated than any rule. Ask, trade, offer, come up with a creative way to both play with the toy. Acknowledge that not all kids communicate well with language, but body language is often more than enough to work on. But this doesn't happen on its own. As the kids get older, they don't communicate constructively on their own, or resolve their own conflicts, but they can do those things. They need help. Not rules, not structures to define their interactions, but they need engaged adults (or older children).
I don't really disagree with this article. But it's a critique that lacks empathy with the parental decisions that got us to where we are, and it does not respond to the concerns those parents have had. I think there's a way to achieve both, parenting isn't a choice somewhere on the line between two extremes, there's no limit to the number of novel and engaged choices available to us.
Interesting about the Master's Degree. In the U.S. teacher education seems unrelated to performance, including Master's Degrees. Which isn't how it should be. It makes me wonder if one of our great flaws here is in how we teach teachers.
The BrowserAPI is certainly not complete, but it's something. Some stuff might be harder than others. Intercepting networking is not very easy in Firefox – you can spy on networking, but the code isn't setup with hooks to change it up. And I don't know if something like localStorage would be exposed via the BrowserAPI – it's more low-level than that sort of thing. But if you are thinking about moving that kind of state around there's another Mozilla project called PiCL: https://wiki.mozilla.org/Identity/PiCL – it's working more in the guts of Firefox, but like much of Firefox it's in Javascript (compared to Chrome which is more biased towards C++). But it's not nearly as friendly an environment as content Javascript :( Anyway, that's more where localStorage manipulation and transportation is going to be happening in Firefox.
Of course it's embedded in Firefox OS, but Firefox OS is really just Firefox built with special options, so in theory with some work you could expose that BrowserAPI to desktop. And there's actually a viable path whereby you could create a new browser as an open web app (https://developer.mozilla.org/en-US/docs/Web/Apps) with the permissions to use the BrowserAPI and it could be installed as a normal application, including on desktop. Of course that's a bunch of steps and unimplemented bits, but you'll be following a path that "upstream" is actually committed to. So committed they actually made just what you describe ;) (Even though the design of the browser is pretty conventional – but it's the concept of a browser-built-on-html that you are exploring at this point.)