“\\b(am|is|are|was|were …|being)\\b”

then

bdy = bdy.replace( … )

only needs to be executed once,I suspect it will make somewhat of a difference

As for your substantive critique:

Fundamentally we need addressability. A client needs to be able to address other clients, and the server needs to be able to address clients on both an individual and a group basis. Pub-sub gives us a powerful method for addressing groups, which individuals are special cases of. Were Bayeux to specify point-to-point messaging, the overhead of specifying group communications would be re-invented for every use-case where you need to address more than one endpoint. By making pubsub part of the spec, we handle the common case in a sensible manner which allows us to optimize for it.

Point-to-point messaging is going to require that there be a mediation service which maps addressable point-names to application-level semantics. This is true no matter how it’s done, and today the simplest way to do this is for clients to subscribe to a “client channel” which messages can be sent to. At one point, there was an implicit client channel created for every connected client in the /meta topic space, and I’m not opposed to adding it back to the spec if we can show that it provides serious value in a common use-case.

As for card dealing, I’m really not sure why you feel that:

a.) Bayeux needs to solve it for you b.) that your app would be less tightly coupled on a point-to-point infrastructure

Firstly, serving cards is a request/response thing to do. Telling groups of users in a game that they should go get cards is a broadcast thing to do. Just tell the clients in the /game/gameid topic to go fetch new cards and have them make an XHR request to the app server!

Trying to encode all of your app logic into Bayeux or viewing it through that lense has never been our intent, and as per your example, using the wrong tool for the job often gets you into a bad place.

As for B, it’s a 2-minute thought experiment to pretty definitively prove to yourself that your app is going to need to handle the concerns of..well, your app.

Regards

Meanwhile, some of your points don’t really apply: for example, in the case of database backends Django deliberately has a pluggable API, so that people who want a backend for a specific DB can develop and use one without assistance from Django itself. Same for the auth system (again, pluggable backends), the session framework (again, pluggable backends), and probably a couple other components will go that way soon as well.

The next big issue is building those “site components” in the right way to allow user flexibility, without creating too much overhead in getting started, and without making users copy code into their projects with no easy-upgrade path once they’ve modified it.

We’ve been kicking around various approaches to that problem, but it is one of the core things we want to get done, because we do believe in code re-use at every level.