Am I hopelessly confused, but can’t “APIs to facilitate sharing connections between [AJAX] frameworks and components” can already be done, at least for Mozilla, using XPCom (which would also put some end to the endless stream of “How do I do synchronous XmlHTTPRequests?” questions
“and Don’t!” answers)…
- Comment
- Reblog
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
DEBEDb 
Synchronous XmlHTTPRequests, that’s a good one. Of course, our site as a “synchonized ( Session ) {” snippet so as to serialize requests from a single browser, to help out those people who feel that clicking more often will make the site work faster. In any case, what exactly is “sharing connections between frameworks” actually mean. On the client browser, or on the server? I can’t see how either really makes sense. If it’s the client, then the client ought to be generating a request *within* a framework and it’s supposed to ship off the xml and be done. What do you want, one framework to use javascript to open a XmlHTTPRequest back to the server, keep the connection open, and pass it off to some other framework — like flash for instance? Now, is that … smart? If it’s the server, well I don’t see how that makes any more sense at all because you already have a server that manages the connections and serves them up to your app server. And a session framework, to make sure the right server gets it.
LikeLike
mep. that was me. I also have the good grammar I see.
LikeLike
I replied to the original but you prolly didn’t get the notification. Let the discussion continue.
LikeLike
That’s true. In any case, if the question is just to synchronize request connections, and the sharing the actual connection has a known solution, then it shouldn’t be hard. You would just have to create a external mutex. If there’s a specific known connection that needs to be shared, then you can do a key lookup into a shared resource. I would NOT try to do Inter Process Communication for messaging on this one. Assuming that both environments share a session key, and you have a pending xml requestion connection that the OS has open. Possibilities that would serve as the shared resource include … … open a lockfile, and piggyback on the OS’s locking. The filename would be the key. … open a database row read-write and let the database lock the other rows. The primary key is the connection key, and have both processes try to, say, increment a counter on that row. When process A is done with the connection, it ups the counter and commits, thereby releasing the lock. The second connection can poll the db periodically to see if the row is updatable. I have this feeling that I’m not understanding the issue, though … ?
LikeLike
> Now, is that … smart? That’s Web 2.1. Or something 🙂 The point was (or I inferred it to be, perhaps, because that’s what I am interested in) is that you may want more than one connection if you have a very rich app. (And you may want synchronous requests sometimes, actually; and now you are reduced to making some modal lightbox/popup that disallows interaction with the app while you are doing something…
LikeLike