bopuc/weblog

You are being consulted!

Daaah... how red faced am I now? ;)
Ok, so my ranting aside, do let me know, anyone, if I'm way of base with anything I said. :)

There are several different issues you bring up in your post for me to reply to.

* First, I heartily concur with you that the capabilities that we desire to offer with SynchroEdit should ultimately be integrated into the web. That is the reason why we are doing this as open source and with the goal of an open protocol. What is ultimately implemented may have no resemblance to this initial implementation.

* Part of the goal of SynchroEdit is to just make it work. There are a number of web standards that we could try to take advantage of to make it work better, but the fact that we are initially focusing on what could be done with Mozilla/Firefox has to do with the ease of integration of new capabilities due to XUL. If we tried to approach this in other ways it would be a lot more difficult, and thus more expensive to develop. Given a much bigger budget, I'd love to build this more in the direction that I believe that you are thinking of. But baby steps for now -- what we've done so far has been done with a remarkably small budget.

* Regarding your list of prospective technologies, it turns out that for synchronous editing we can't quite use the set you suggest. For instance, VCS does not address quite the right problem. VCS is focused on versioning, not replicating changes live across multiple locations while changes are simultaneously being made. There is a lot of research here, try "optimistic concurrency control" as a keyword in google.

* The protocol behind SynchroEdit we hope to be independent of the specific implementation. The particular technique we have chosen to focus on is DOM synchronization (the solution is more or less basically a DOM transporter between multiple clients; the specifics on server/client software is almost irrelevant). Basically, we are synchronizing the DOM between multiple machines. DOM is a W3C standard, and as it evolves I'm sure that people will find more uses for DOM synchronization than just simultaneous editing.

* The current Javascript signed-JAR solution that we are using in SynchroEdit is a kludge -- it allowed us to create a streaming connection to the server. Our goal in the next release is to use XMLHttpRequest, and use a trick keep the server to client http connection open. Unfortunately, we can't do the same from client to server, but if SynchroEdit as a proof-of-concept is successful, we can hopefully influence the future of XMLHttpRequest to allow continuous connections both ways.

* Finally, I'd love to have broader participation in SynchroEdit -- the wiki is open now, and if there are some funding and coding sources available to move this toward your vision, I'd welcome their involvement.

Two simple questions for now. I will expand on the discussion later on.

* What are the starting requirements for your application/developments?
* Why through a Web browser more than an application ala SubEthaEdit? (What is the benefit?)

I'll take the second question -- duh!

Kidding,
Ross

The current SynchroEdit uses javascript on the client and a java server. However, the protocol is server independent, and I expect that we'll move away from java in the near term.

As for why not an application -- maybe I should turn the question around, why not in the browser? That is increasingly where web content is being created. Thus the synchronous editing tool should be where the content is.

Hi gentlemen, thanks for the responses.

This thread is going to get very fragmented very quickly, but here goes:

Christopher, one of my points is that some of this functionality is already "integrated into the web". We agree that "in-browser editing" is a good thing.

I could rave on about HTTP PUT and XUL and DOM and XFORMS and even XMLhttpRequest; all good technologies that are proven and implemented and used, but I realise now that that is not what is at issue at all.

What is at issue here is the statelessness of HTTP, which is what all this "Web2.0-dubbed" whackiness is trying to hack around, essentially. Doing this is, fundamentally, trying to make the web do something it is not designed to do. I have no real objection to this as I accept that systems evolve over time, but then you must undertsand Karl's question of "why not via another application?": Remember that HTTP is in the "application layer" of the TCP/IP stack.

I can totally see where you guys are coming from, and undertsand and accept it. And for what you want to do, stateful synchronous communications, in the existing landscape, which is the widespread use of some parts of HTTP, I can even see how your solution makes sense.

Perhaps I've gown a bit cynical recently by observing too many people trying to throw in the kitchen sink to the detriment of those who just want to wash their dishes, and doing so using duct tape and kludges instead of threaded pipes and washers. The perfectionist in me hates it, but I also realise there is no such thing as perfect. Or even ideal, in many cases. ;)

Just for your info, the current version uses a streaming connection, rather then a stateless connection -- the problem is that in order to get priviledges for that you have to sign the javascript JAR file. That is why we are switching to the XMLHttpRequest technique, as a security dialogue has been too high a barrier of entry for many people.

Our goal with the next version is to write some Javascript code coerces XMLHttpRequest into looking like a stream. However, the protocol itself will probably remain streaming oriented.

A kludge I'm not completely happy with, but again, making it work first is important, then we can refine and try go get help from browser vendors and other tools vendors to do it architecturally correct.

I'd love to hear more on what your thoughts on the topic are. I've checked in on this post occasionally but I realize (probably a little late) that it has died.

The concept behind SynchroEdit as I (personally) see it is not an implementation at all. It's more of a concept which could be implemented in any number of ways. I can see for example a server-less solution (we even discussed writing one) between multiple clients. Is this what you're bugged about -- the necessity for a server implementation to pull off what probably might be doable without a server?

Anyway, feel free to contact me if you wish. :)