Statement of Support
Hi Ernest,
I want to express my hope that this project makes it to a functional state. In light of the recent code update, I tried the project out, and it doesn't seem to be working. I think this project is very cool, and I would love to help out. But, since I don't know any of the technology that you are using, I probably won't be able to help until it is functional.
Any updates as to where you are at with the project are eagerly appreciated.
Dan
Groups:
Login to post comments
The project needs tlc.
The project needs tlc. That's fairly obvious. Ernest had ideas to refactor the code to bring it up to date. With the drupal 5 changes it shouldn't be a difficult task. If I had the time I would do it myself, but can't promise right now.
The updates required are refactoring to use jquery properly and defining a 'live update' callback, essentially a js hook for editors. Integration with js editors like tinyMCE, widgeditor, ...
Ernest ping What are your
Ernest ping
What are your plans with the code? Can you coordinate the update?
Still alive
pong!
I'm so excited about Dan's interest. It's about time to make this module something cool and useful. I'll be working this weekend to tidy up this mess and to make a proper to do list so that Dan, Vlado and I can work better with the code
Ernest
Ernest,I'm a bit on the
Ernest,
I'm a bit on the busy side at the moment, but hope to free some time and have a go at helping with polishing this one.
What do you think of something along the lines (5.x)
* re-use jquery as much as feasible
* in js provide update callbacks/messages
* keep the current simple editor, but twist it's arms to use the above callbacks
* try and make a heavy (tinymce,fckedit,...) editor plugin (that is something good, but I have no clue if it is feasible)
Hi all, After reviewing
Hi all,
After reviewing jQuery documentation, I am all on-board with making this a 5.x only project. I conceptually like jQuery allot. Here is the direction I think we can go (I think I get what dikini is saying):
Make this a hidden module that is enabled by other modules. We can make a jQuery plug-in, that sets up the editor, and the communication with drupal. The plug-in would take in an ID. When a person submits data, the plugin would send the data to the module, along with the ID. The module would then invoke a custom hook, send out the update, and id, to whatever other module requests it, presumably, the modules that enabled the editor in the first place.
I have programed some skeletons of such. You can find an example of its usage on my personal website here: http://hollocher.is-a-geek.com/drupal/?q=node/22
All it does is add a highlight to the "content" div, which is both the text, and the side bar.
But, its a module, and a jQuery plug-in.
http://hollocher.is-a-geek.com/drupal/?q=node/21
Here, you will find the code of someone else's inline editor. I think this is a good direction for the gui. I want to start adding some of its principles to the module that I already created, but before I proceed too much, I'm hoping to have a discussion about the highlevel design of the project. My hope there is that once that is hashed out a bit, I can actually start contributing some code to the project.
Ernest: Where you at?
Dan
PS - those links are to my personal website, running on my personal computer. I do turn my computer off at various times, so the website isn't always available.
Still alive
pong!
I'm so excited about Dan's interest. It's about time to make this module something cool and useful. I'll be working this weekend to tidy up this mess and to make a proper to do list so that Dan, Vlado and I can work better with the code
Ernest
Permissions
Hi,
Dan asked me about using permissions for the different parts of a same shared document. As the module is working on the native text areas of the Drupal forms the content would need to be split in different blocks and handle different asynchronous communications for each of them. The cleverest pattern to carry this out would be working on a common object (blockObj) which would have implicit methods (the same we have now as separate functions) for establishing the remote calls. For a braver optimization, a new object could be created every time the user types a new chunk of content. This kind of locking would be more intended for an internal diff and patch optimization than an external paragraph locking logic. I think the best way to establish a lock system would be using the php semaphores (http://www.php.net/manual/en/ref.sem.php). If you have any other methods in mind let me know.
BTW, in the version 5 of drupal the drupal.js has changed with new jQuery functions. I'm fixing these js changes but, how can one upload both versions (the 4.7 and the 5 compatible) to the CVS properly in order to mantain both at the same time? Should I create a new thread for the one compatible with the version 5?
Use this files to get a functional module with the version 4.7:
collaborative_editor.module
drupal.collaborative_editor.js
drupal.collaborative_editor_ui.js
Don't forget to follow the install instructions
several questions and comments
Semaphores:
I think semaphores a re a natural choice. We might, in fact, be limited to semaphores. I thought that the nuts and bolts of data-locking had to be implemented at the OS level, or maybe even the hardware level. So, we may be limited to what php offers, which isn't really a bad thing.
COMET vs AJAX:
Are you using COMET or AJAX, right now? Is COMET even possible, at this time? I looked at the link that you have posted, and there were no details of an API of sorts. I originally figured that COMET would use the same basic components that AJAX uses, but setup a bit differently. The article talked about people having to use "hacks" to make COMET happen, which made me question my original assumption. Anyway, I would like to know more about COMET, if you have other resources.
4.7 vs 5.x:
I have seen other modules claim that they are 5.x only, since they use jQuery. Maybe you want to go the same route? I, personally, will install whatever you want to support. But, it seems reasonable to make this project 5.x only.
As for the cvs, I don't know.
For myself, I have gone through several small tutorials. I am next going to look at jQuery, and then I will start trying to understand what you have done. I am already curious to know what the state, or model, looks like. Do users login, and their changes don't get committed till they logout? I'll have to look at it more.
The original code uses
The original code uses simple line/paragraph locks, which prohibit the editing of lines. Since there is a heartbeat, we can expire the locks safely in its absence. Semaphores will complicate the code too much. The problem is not in implementing the queues, that is trivial, but the UI and related. The benefits will be very few IMO.
COMET vs AJAX:
currently AJAX. COMET with php is possible, albeit with configuration twists and turns. Is it scalable and safe? I'm not so sure about it :( Mind you that is a php specific issue. The problem lies with keeping a long running, kind of daemonised php process (or apache with php). Depending on programming there is a big danger of memory leaks. I haven't tested it, but circular structures together with typical reference counting usually means memory leaks. So I personally try to avoid those in long term php processes. The problem is we can't guarantee that, and if there is a suitable replacement, maybe not so efficient, but still a safer one, why not use that?
4.7 vs 5.x, aka jQuery
+1
This is one of the most
This is one of the most interesting projects I've seen so far. I hope there's still interest in possibly getting a new release out the door.