On 02/10/2014 05:47 PM, Ludovic Dubost wrote: > Hi Caleb > > I gave it a try and the first impression is quite nice. We got rid of the > issues we had with the non text area used in the previous one. > > Le lundi 10 février 2014, Caleb James DeLisle <[email protected]> a écrit : > >> Hi Paul, >> >> This is an interesting idea, being able to dump the core state of the >> engine. >> I did not know that the old Jupiter based engine was able to become >> desynchronized, >> thanks for the information. >> >> The cjdrt engine is based on a unique design which is more similar to >> Bitcoin than >> it is to any previous realtime engine. This design forces the clients to >> eventually >> come to consensus on something (even if it's wrong). If you open the >> console, you > > > On this does it mean there is no OT at all ? And we are not using Jupiter > anymore ?
Technically it falls in the category of OT but whereas the previous project used a Jupiter implementation which was spread between the server and the client, this is a (the first ever) pure client-side implementation written entirely by me and which should solve the problems that made WYSIWYG and portability so difficult. Thanks, Caleb > > Ludovic > > > >> will see the engine is still configured to log debug messages explaining >> what it's >> doing but unfortunately if there is a real bug which causes desync, the >> historical >> information of where the node went wrong is not going to be available at >> this time >> but I'll take this under consideration and if any bugs do turn out to crop >> up, I >> will be fast-tracking this idea. >> >> Thanks, >> Caleb >> >> >> On 02/08/2014 05:37 AM, Paul Libbrecht wrote: >>> Caleb, >>> >>> another wish to make it production ready: include a good "debug dump" >> function so that users can produce reports when testing it. >>> >>> We've been trying the earlier version of the real-time-editor (it's >> still there actually) and had quite an amount of surprising effects; some >> of them may be related to paste, but not only. I had the impression of >> regularly meeting a garbage state at the server, where different clients >> had different views (we were speaking in Skype). The only way I could fix >> the inconsistency was to restart the server. Hence the suggestion of a >> stronger reporting facility so that such critical situations can be >> reported about and tackled in a maturation cycle out in the wild. >>> >>> paul >>> >>> >>> Le 8 févr. 2014 à 10:39, "[email protected]" <[email protected]> a >> écrit : >>> >>>> Hi Caleb, >>>> >>>> I've just tried and it works well! Well done this is very cool :) >>>> >>>> Now if we want to make this production-ready we would need (IMO) at >> least one additional feature which is the ability to view the list of other >> users editing the page and color markers per user to show who's adding what. >>>> >>>> Note that I haven't checked the code yet. Is it some prototype-quality >> code or is it following the xwiki core rules and ready for being maintained? >>>> >>>> I guess you've also used some hacks for lack of UI extension points (as >> in the lock screen and on the edit screen where you added some extra text >> which I assumed you implemented in Javascript?) which would need to be >> added. >>>> >>>> Thanks >>>> -Vincent >>>> >>>> On 6 Feb 2014 at 06:42:03, Caleb James DeLisle ([email protected] >> (mailto:[email protected])) wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'm very pleased to announce two new extensions to come out of >> XWikiSAS Research >>>>> and the RESILIENCE Research project. >>>>> >>>>> Number One: WebSockets in XWiki! >>>>> If you're an extension developer like me, you want events, you want >> stuff in the >>>>> browser to be talking to stuff in the wiki and you don't want to be >> messing around >>>>> with Jetty and Tomcat and all different kinds of libraries and >> configuration every >>>>> time you need to write an application. You just want stuff that works. >>>>> Here it is: >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/WebSocket >>>>> Include this as a dependency for your extension and the Extension >> Manager will >>>>> automatically include it when users install your extension. In just a >> few lines of >>>>> code, your users can be chatting and collaborating through the >> websocket and it's >>>>> based on Netty (Special thanks to the Atmosphere project for >> developing Nettosphere) >>>>> so it works in all versions of Tomcat and Jetty and does not need any >> changes to the >>>>> front-end server, just open a port on the JVM machine and you're done. >>>>> >>>>> Number Two: A new Realtime Collaborative WikiText Editor. >>>>> Indeed this is not the first attempt at Realtime Collaborative editing >> but perhaps >>>>> it is the most academically amusing. Really this is a prototype to get >> a handle on >>>>> the technology before we make the leap into Realtime WYSIWYG. Whereas >> the previous >>>>> Realtime Collaborative WikiText editor had performance issues and was >> unable to >>>>> handle large pasted, the new editor uses a completely novel design >> which is intended >>>>> to not only port well to WYSIWYG editing but is implemented entirely >> on the client >>>>> with the server only relaying messages, making it portable to >> different web frameworks. >>>>> >>>>> Check out the Realtime Collaborative WikiText Editor here: >>>>> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/RealTime+Wiki+Editor >>>>> >>>>> or install it with the Extension Manager to give it a try for yourself. >>>>> >>>>> Disclamer: This is still new and might not work pro > > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
