Form Demo Bug
Nick Retallack
your change is lost.
I couldn't find an issue tracker for this project, so I'll report this
here.
Avery Pennarun
The MobWrite maintainers seem to have died and/or been disappeared by
the Google Mafia. But I have experienced this bug myself and I agree
it's annoying.
In the event that you can figure out how to fix it, I'll be happy to
accept your patch into my fork of the code at
http://github.com/apenwarr/mobwrite :) (You probably want to use my
tornado-daemon branch, even if you don't use tornado, as it already
has a couple of bugfixes.)
Have fun,
Avery
Mikey
Im unsure as to whats happened to Neil but he is normally not to far
away!
As for your bug, I have no clue as to the problem but is confirmed to
be the same here too.
I however have forked away from Mobwrite aswell (similar to tornado?).
I have implemented mobwrite as the HTTP method "PATCH", completely
removing the mobwrite protocol and making it somewhat incompatible
with mobwrite.
I shell dive into Mobwrite once more and have a look, otherwise i
shell let neil know =]
MikeyB
Avery Pennarun
> I however have forked away from Mobwrite aswell (similar to tornado?).
> I have implemented mobwrite as the HTTP method "PATCH", completely
> removing the mobwrite protocol and making it somewhat incompatible
> with mobwrite.
What server do you use that allows you to implement a separate HTTP method?
Avery
Mikey
Current stable server (which i use regularly) is written in python,
and is a homemade webserver.
However, My super cheap webhosting doesn't allow me to run my own
webserver, and so i have been working (i say working, its very slow
development cycles ;)) on an Apache mod, which is basically a htaccess
file which redirects any PATCH requests to the processing file.
A plugin for Apache or Lighttpd would be the best solution, but not
something ive really thought about.
I try to fully conform to the PATCH standard,
http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-16.html
which is only a draft at the moment.
The principles are exactly the same as mobwrite, with only a few
alterations. A use of a checksum instead of an incremental "version"
number which helps with caching and decentralisation, and the use of
"GET" to receive the initial data which untangles alot of code.
Removing the "GET" from patch means that the users edits are NEVER
lost when they are too far out of sync. The idea behind that was that
I believe that the CLIENT should be the only one to make collision/
error decisions. And so if the server is unable to apply my changes
because it does not have the correct copy of the shadow file, it will
return an error, the CLIENT then downloads the current copy of the
data, does a 3way diff of the 3 versions it has (current, shadow,
clienttext) and sends the new PATCH.
If a collision is detected, the client (which is a gedit plugin) is
notified and the client must handle accordingly. Currently if its
within typing range, it simply drops the conflict, if it is not within
typing range it will pop up a window with a list of changes that you
can select to apply, not apply etc. This is actually nice, because i
can now work offline, or on a very bad connection, make tons of
changes, and when i press the "Sync" button if there are some
conflicts I know via a nice pop up window. And if im on a fast
connection doing realtime typing i can instantly see my changes I have
just typed change.
A few other bits, like being able to select the "diff-match-patch"
part with the use of Content-Type, helped when i was messing around
with XML syncing.
The move to HTTP made alot of sense to me, I only really want to sync
files. Which tbh is what is the difference from mobwrite. Mobwrite was
designed for sharing web-objects like textareas or forms.
MikeyB
On 16 Feb, 01:32, Avery Pennarun <apenw...@gmail.com> wrote:
Avery Pennarun
> Current stable server (which i use regularly) is written in python,
> and is a homemade webserver.
>
> However, My super cheap webhosting doesn't allow me to run my own
> webserver, and so i have been working (i say working, its very slow
> development cycles ;)) on an Apache mod, which is basically a htaccess
> file which redirects any PATCH requests to the processing file.
>
> A plugin for Apache or Lighttpd would be the best solution, but not
> something ive really thought about.
Really? It seems odd that a web host would let you add binary
extensions into your apache server (which fundamentally means you
could alter your apache server, one way or another, to do *anything*)
but doesn't let you run your own alternative web server. How does
that work?
If they let you run daemons at all, you could run a tornado server and
have your apache/lighttpd/etc just proxy connections to it, which is
how it's meant to be used.
> Removing the "GET" from patch means that the users edits are NEVER
> lost when they are too far out of sync. The idea behind that was that
> I believe that the CLIENT should be the only one to make collision/
> error decisions.
Interesting. Most version control systems (eg. git, svn, cvs, etc)
follow that same convention, but it seemed to me that something
designed along the lines of mobwrite would benefit from having the
server resolve the conflicts. Otherwise you end up implementing
collision-resolution algorithms in javascript, which doesn't sound
very fun (particularly for unit testing and debugging).
> If a collision is detected, the client (which is a gedit plugin) is
> notified and the client must handle accordingly. Currently if its
> within typing range, it simply drops the conflict, if it is not within
> typing range it will pop up a window with a list of changes that you
> can select to apply, not apply etc. This is actually nice, because i
> can now work offline, or on a very bad connection, make tons of
> changes, and when i press the "Sync" button if there are some
> conflicts I know via a nice pop up window. And if im on a fast
> connection doing realtime typing i can instantly see my changes I have
> just typed change.
I gathered that mobwrite is mostly about the real-time syncing. If
you're not syncing in real time anymore, it does make sense that you
would have forked it and gone in an entirely different direction.
Things like conflicts would suddenly become a major issue, where
mobwrite mostly doesn't have to care about them.
Have fun,
Avery
Mikey
> On Tue, Feb 16, 2010 at 6:39 PM, Mikey <mikey...@gmail.com> wrote:
> > Current stable server (which i use regularly) is written in python,
> > and is a homemade webserver.
>
> > However, My super cheap webhosting doesn't allow me to run my own
> > webserver, and so i have been working (i say working, its very slow
> > development cycles ;)) on an Apache mod, which is basically a htaccess
> > file which redirects any PATCH requests to the processing file.
>
> > A plugin for Apache or Lighttpd would be the best solution, but not
> > something ive really thought about.
>
> Really? It seems odd that a web host would let you add binary
> extensions into your apache server (which fundamentally means you
> could alter your apache server, one way or another, to do *anything*)
> but doesn't let you run your own alternative web server. How does
> that work?
>
> If they let you run daemons at all, you could run a tornado server and
> have your apache/lighttpd/etc just proxy connections to it, which is
> how it's meant to be used.
>
I think there's been a misunderstanding, the current solution is to
use htaccess files. Which are basically plain text conf files for
apache. It tells apache to redirect the request to a python or php
script.
An apache mod would be the better solution, as its just providing the
PATCH http method. Which is completely generic and could be used by
anyone.
> > Removing the "GET" from patch means that the users edits are NEVER
> > lost when they are too far out of sync. The idea behind that was that
> > I believe that the CLIENT should be the only one to make collision/
> > error decisions.
>
> Interesting. Most version control systems (eg. git, svn, cvs, etc)
> follow that same convention, but it seemed to me that something
> designed along the lines of mobwrite would benefit from having the
> server resolve the conflicts. Otherwise you end up implementing
> collision-resolution algorithms in javascript, which doesn't sound
> very fun (particularly for unit testing and debugging).
>
I opted for Client side because;
* The client application has more information, so if an automated
"fix" is possible (unlikely) is best chances are here
* Most conflicts I deal with (plain text & XML) are typed by a user,
and most likely can only be fixed by a human
* If there is a conflict, regardless of situation, the user wants to
know about it
and I believe serverside collision resolving is not possible.
Collisions are application bound (the patches depend on how they are
used) so an automated fix may change the semantics (meaning) of the
data;
e.g.
Original = "Mike is 50"
You change it to = "Mike is not 50" (+not)
and i change it to = "Mike is 23" (-50 +23)
The result could be = "Mike is not 23"
Which is an incorrect statement, while both edits are valid. This
becomes even worse with XML and text that needs structure.
and the server is really just a HTTP webserver so very generic. (for
me anyway)
> > If a collision is detected, the client (which is a gedit plugin) is
> > notified and the client must handle accordingly. Currently if its
> > within typing range, it simply drops the conflict, if it is not within
> > typing range it will pop up a window with a list of changes that you
> > can select to apply, not apply etc. This is actually nice, because i
> > can now work offline, or on a very bad connection, make tons of
> > changes, and when i press the "Sync" button if there are some
> > conflicts I know via a nice pop up window. And if im on a fast
> > connection doing realtime typing i can instantly see my changes I have
> > just typed change.
>
> I gathered that mobwrite is mostly about the real-time syncing. If
> you're not syncing in real time anymore, it does make sense that you
> would have forked it and gone in an entirely different direction.
> Things like conflicts would suddenly become a major issue, where
> mobwrite mostly doesn't have to care about them.
>
Well. I did try and convince neil that this way would be better, tho i
still hope he takes on some of the suggestions as they solve some
problems that mobwrite has. they do create some too, such as I can
only currently do one request per connection, where mobwrite can group
them together. Not a big issue when you only have one textarea
syncing, but a whole form maybe an issue.
MikeyB
> Have fun,
>
> Avery
Avery Pennarun
> I think there's been a misunderstanding, the current solution is to
> use htaccess files. Which are basically plain text conf files for
> apache. It tells apache to redirect the request to a python or php
> script.
>
> An apache mod would be the better solution, as its just providing the
> PATCH http method. Which is completely generic and could be used by
> anyone.
I think apache modules are pretty outdated. The problem with them is
you then need a python interpreter (or whatever) for every single copy
of the apache process, even ones just sending static files, which is
wasteful.
If you instead used something like fastcgi or proxy, you could have a
small number of threads for your conflict resolution, and a large
number of (now lighter weight) apache processes for handling
everything, including usually mostly static files.
This is the model used by django/tornado. And you get a huge
performance increase moving from mod_php to mod_fcgi with a php fcgi
daemon, for example.
> Well. I did try and convince neil that this way would be better, tho i
> still hope he takes on some of the suggestions as they solve some
> problems that mobwrite has. they do create some too, such as I can
> only currently do one request per connection, where mobwrite can group
> them together. Not a big issue when you only have one textarea
> syncing, but a whole form maybe an issue.
The neat thing about real-time synchronization is it just stops being
a problem. The faster you sync, the less of a problem it becomes. It
reaches the point where I can't even type two characters before
resyncing; in case of a conflict in that case, it'll be *right at my
cursor* and there's no chance I'll miss it. Which is totally easy for
any user to understand (as opposed to conflict resolution, which only
developers understand).
However, it also doesn't work with everything. If you have clients
doing batch updates of more than a character at a time, you absolutely
need conflict resolution. And I agree that trying to resolve complex
conflicts like that on the server side is a losing battle.
So anyway, more power to you :) But I think it stops being mobwrite
at that point, and starts being git instead.
Have fun,
Avery
Mikey
On 19 Feb, 03:24, Avery Pennarun <apenw...@gmail.com> wrote:
> On Thu, Feb 18, 2010 at 7:04 PM, Mikey <mikey...@gmail.com> wrote:
> > I think there's been a misunderstanding, the current solution is to
> > use htaccess files. Which are basically plain text conf files for
> > apache. It tells apache to redirect the request to a python or php
> > script.
>
> > An apache mod would be the better solution, as its just providing the
> > PATCH http method. Which is completely generic and could be used by
> > anyone.
>
> I think apache modules are pretty outdated. The problem with them is
> you then need a python interpreter (or whatever) for every single copy
> of the apache process, even ones just sending static files, which is
> wasteful.
Heya. Im not a fan of apache either, however the rest of the world is.
With such a large amount of servers running apache it makes sense to
provide support for it first.
Apache modules are written in C and require no external interpreters.
However you did remind me of the fundamental problem with google-diff-
match-patch which is that its C/C++ version isn't quite up to par.
(and most prolly why i stopped/slowed development)
>
> If you instead used something like fastcgi or proxy, you could have a
> small number of threads for your conflict resolution, and a large
> number of (now lighter weight) apache processes for handling
> everything, including usually mostly static files.
>
My server takes a completely different approach to the whole problem
than mobwrite does. there is no mobwrite server or equivalent. It
really is just a webserver. No PHP/Python or script is required.
Apache handles the entire request. Just like it does with a GET,
DELETE, POST, PUT (In the RESTful sense).
The changes I have made make the server completely stateless. Which is
the key difference.
> This is the model used by django/tornado. And you get a huge
> performance increase moving from mod_php to mod_fcgi with a php fcgi
> daemon, for example.
>
> > Well. I did try and convince neil that this way would be better, tho i
> > still hope he takes on some of the suggestions as they solve some
> > problems that mobwrite has. they do create some too, such as I can
> > only currently do one request per connection, where mobwrite can group
> > them together. Not a big issue when you only have one textarea
> > syncing, but a whole form maybe an issue.
>
> The neat thing about real-time synchronization is it just stops being
> a problem. The faster you sync, the less of a problem it becomes. It
> reaches the point where I can't even type two characters before
> resyncing; in case of a conflict in that case, it'll be *right at my
> cursor* and there's no chance I'll miss it. Which is totally easy for
> any user to understand (as opposed to conflict resolution, which only
> developers understand).
>
Exactly, if the user can see the change (And hence in his viewing
area). It simply changes and they can sort it out for themselves.
> However, it also doesn't work with everything. If you have clients
> doing batch updates of more than a character at a time, you absolutely
> need conflict resolution. And I agree that trying to resolve complex
> conflicts like that on the server side is a losing battle.
>
Yes, the more edits the bigger the problem. This can also happen on
bad connections and so mobwrite isnt entirely immune from it. Tho like
you said, working offline, which is something I need to support,
creates conflicts so you have to provide something else (hence the
popup window).
> So anyway, more power to you :) But I think it stops being mobwrite
> at that point, and starts being git instead.
>
The bridge between git and mobwrite is exactly what im after! ;)
I will try and upload the client and webserver somewhere once im back
at my computer. Might make some more sense then.
> Have fun,
>
> Avery