11 Feb
2014
11 Feb
'14
5:04 a.m.
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 <cjd(a)hyperboria.ca> a écrit :
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
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 ?
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, "vincent(a)massol.net" <vincent(a)massol.net> 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 (cjd(a)hyperboria.ca
(mailto:cjd@hyperboria.ca)) 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