Re: A Wavy Future

[Evan Hughes]

The cwiki seems to be best place for the time being, anyone wanting to
contribute let the mailing list know for writing permissions.

https://cwiki.apache.org/confluence/display/WAVE/A+Wavey+Future

On Sat, 19 Mar 2016 at 18:55 Evan Hughes  wrote:

> Whats the best way we can collab on a protocol spec.
>
> On Sat, 19 Mar 2016 at 07:05 Thomas Wrobel  wrote:
>
>> As for the differences to Pie...I cant tell because there seems to be
>> very little information on Pie online, nor a working copy.
>> Id guess however Pie is a closed, unfederated messaging system though.
>> Can previous messages be edited? is the conversation thread
>> non-linear?
>> The differences between a wave server/client system and a (typical) "
>> fun messaging app" would be quite a lot.
>> --
>> http://lostagain.nl <-- our company site.
>> http://fanficmaker.com <-- our, really,really, bad story generator.
>>
>>
>> On 18 March 2016 at 18:26, Yuri Z  wrote:
>> > There is at least one commercial successor -
>> https://www.co-meeting.com/
>> > There was also another commercial attempt, which failed but is now open
>> > sourced - https://github.com/jorkey/Wiab.pro
>> >
>> > On Fri, Mar 18, 2016 at 12:29 PM Adam Bielski
>> 
>> > wrote:
>> >
>> >> Hiya all!
>> >> I am new to this mailing group and I wanted to further understand the
>> >> limitations OR differences that WiaB provides in comparisson to:
>> >>
>> >>
>> >> https://www.crunchbase.com/organization/pie-computing#/entity
>> >>
>> >> And WHY has there not been a successor (based on the GOOGLE WAVE
>> project)
>> >> that has ever been launched for commercial use!?
>> >> Cheers!
>> >> Adam
>> >> 2:29 środa, 2016-3-16, Evan Hughes  napisał(a):
>> >>
>> >>
>> >>
>> >>
>> >> Sorry many mistakes, currently on mobile. Meant to say "the OS editors
>> arnt
>> >> bad but."
>> >> On 16/03/2016 11:18 AM, "Evan Hughes"  wrote:
>> >>
>> >> > I had a look at quill and react seperatly dismorning, interestingly
>> the
>> >> > atom editor is built using react and they have done at least one if
>> not
>> >> > more about how they get more performance out of it, moving rendering
>> to
>> >> the
>> >> > gpu and such.
>> >> >
>> >> > Do you think itll actually be possible to remove ot somewhat from the
>> >> > client,  how do we efficently send data to the client that the
>> document
>> >> has
>> >> > changed.
>> >> >
>> >> > Also we must be very careful abiut what editor we choose if we arnt
>> >> > building one inhouse, debugging could destroy us all.
>> >> >
>> >> > But the c-rendering we could do inhouse then we would have a basis
>> for
>> >> > creating a c-editor from scatch. Not that the OS projects are bad but
>> >> its a
>> >> > pretty broad featire set we need.
>> >> > On 16/03/2016 11:00 AM, "Joseph Gentle"  wrote:
>> >> >
>> >> >> Sorry, just poking in here -
>> >> >>
>> >> >> A couple of years ago I worked with QuillJS's author to add OT to
>> >> >> quill. Its a rich text editor, which emits user events and Jason
>> (the
>> >> >> author) has a module which interprets those events, builds
>> operations
>> >> >> and can do OT with them. It doesn't support rich embedding of
>> >> >> components yet, but he's working on that now.
>> >> >>
>> >> >> React's Draft-js might also work well.
>> >> >>
>> >> >> -J
>> >> >>
>> >> >> On Wed, Mar 16, 2016 at 11:18 AM, Michael MacFadden
>> >> >>  wrote:
>> >> >> > All,
>> >> >> >
>> >> >> > A few things on the editor.  For one.  I think ACE is a plain text
>> >> >> editor, which I have used for a bunch of things.  Has a great API
>> for
>> >> >> collaboration integration, but it is not rich text, which is what
>> wave
>> >> is
>> >> >> all about.  So I don’t think that will work.
>> >> >> >
>> >> >> > Also, I think perhaps I should clarify the term editor.  I
>> probably
>> >> >> used in inappropriately.
>> >> >> >
>> >> >> > There are two parts to be concerned with.  The first is
>> collaborative
>> >> >> rendering.  If you are just looking at a blip, you can still see it
>> >> change
>> >> >> in real time.  So this would be collaborative rendering.  Then when
>> you
>> >> are
>> >> >> actively editing a blip, you need a collaborative editor.  Both are
>> >> >> important.
>> >> >> >
>> >> >> > The main performance issue comes in two places.  First I may have
>> a
>> >> >> conversation model that contains hundreds of blips.  Some sort of
>> lazy
>> >> >> loading strategy here is probably required and smart attaching and
>> >> >> detaching of listeners.  If you have hundreds of blips all rendered
>> at
>> >> once
>> >> >> and all having to have listeners attached to them because any one of
>> >> them
>> >> >> can change at any time you can run into rendering performance
>> issues.
>> >> >> Secondarily, if you do have lots of people editing lots of blips,
>> much
>> >> of
>> >> >> that 

Speed issues of wiab resolved and open sourced on github

[Kirill Kostyuchenko]

Hello developers!

We released our features to github repository
https://github.com/jorkey/Wiab.pro

The key features is indexed delta storage and new rendering mechanism.

Re: A Wavy Future

[Michael MacFadden]

Joseph,

I have used quill a bunch.  Great editor.  I think it would be close to what we 
need.


Evan,

Yes, the editor really shouldn’t know anything about OT at all.  Even if we 
were to make an editor of our own, I would strongly suggest not letting the OT 
internals make it all the way into the editor.  OT will take care of making 
sure operations are transformed into the correct state space such that the end 
result can simply be calling an API on the editor that says (insert text here).

~Michael



On 3/15/16, 6:29 PM, "Evan Hughes"  wrote:

>Sorry many mistakes, currently on mobile. Meant to say "the OS editors arnt
>bad but."
>On 16/03/2016 11:18 AM, "Evan Hughes"  wrote:
>
>> I had a look at quill and react seperatly dismorning, interestingly the
>> atom editor is built using react and they have done at least one if not
>> more about how they get more performance out of it, moving rendering to the
>> gpu and such.
>>
>> Do you think itll actually be possible to remove ot somewhat from the
>> client,  how do we efficently send data to the client that the document has
>> changed.
>>
>> Also we must be very careful abiut what editor we choose if we arnt
>> building one inhouse, debugging could destroy us all.
>>
>> But the c-rendering we could do inhouse then we would have a basis for
>> creating a c-editor from scatch. Not that the OS projects are bad but its a
>> pretty broad featire set we need.
>> On 16/03/2016 11:00 AM, "Joseph Gentle"  wrote:
>>
>>> Sorry, just poking in here -
>>>
>>> A couple of years ago I worked with QuillJS's author to add OT to
>>> quill. Its a rich text editor, which emits user events and Jason (the
>>> author) has a module which interprets those events, builds operations
>>> and can do OT with them. It doesn't support rich embedding of
>>> components yet, but he's working on that now.
>>>
>>> React's Draft-js might also work well.
>>>
>>> -J
>>>
>>> On Wed, Mar 16, 2016 at 11:18 AM, Michael MacFadden
>>>  wrote:
>>> > All,
>>> >
>>> > A few things on the editor.  For one.  I think ACE is a plain text
>>> editor, which I have used for a bunch of things.  Has a great API for
>>> collaboration integration, but it is not rich text, which is what wave is
>>> all about.  So I don’t think that will work.
>>> >
>>> > Also, I think perhaps I should clarify the term editor.  I probably
>>> used in inappropriately.
>>> >
>>> > There are two parts to be concerned with.  The first is collaborative
>>> rendering.  If you are just looking at a blip, you can still see it change
>>> in real time.  So this would be collaborative rendering.  Then when you are
>>> actively editing a blip, you need a collaborative editor.  Both are
>>> important.
>>> >
>>> > The main performance issue comes in two places.  First I may have a
>>> conversation model that contains hundreds of blips.  Some sort of lazy
>>> loading strategy here is probably required and smart attaching and
>>> detaching of listeners.  If you have hundreds of blips all rendered at once
>>> and all having to have listeners attached to them because any one of them
>>> can change at any time you can run into rendering performance issues.
>>> Secondarily, if you do have lots of people editing lots of blips, much of
>>> that will not be “on screen” for a given user, and you don’t want to be
>>> processing all of those events and messing with the DOM if you don’t need
>>> to.  So there are performance and complexity issues there.
>>> >
>>> > Then there is the actual editor.  Building a Rich Text Editor is not
>>> trivial (still.. How can this be???).  So you have to deal with all the
>>> issues of building a rich text editor.  Then on top of that you want to
>>> integrate remote cursors, selections, authorship, etc. into that editor.
>>> Most editors do not have that (a few do, and some are easier than others to
>>> add that).  So there is complexity here as well.
>>> >
>>> > If you want to use an open source editor you need one that does the
>>> kind of rich text editing you want to do. It needs to either have the
>>> collaboration capabilities (shared cursors, etc.) that you want, or it has
>>> to be reasonably easy to implement them yourself.  And it needs to have a
>>> good enough eventing API for you to hook into it to capture local changes,
>>> and to have API to allow you to drive remote changes into it.
>>> >
>>> > The point being that, the conversation renderer and rich text editor is
>>> a very non-trivial component, if the assumption is to roughly replicate
>>> what is there.
>>> >
>>> >
>>> > One point I definitely agree with is that the editor itself really
>>> should know nothing about OT.  It should be decoupled and just needs to
>>> have a good API with good events.
>>> >
>>> > ~Michael
>>> >
>>> >
>>> >
>>> >
>>> > On 3/15/16, 10:11 AM, "Pablo Ojanguren"  wrote:
>>> >
>>> >>Talking about editors I suggest ace 

Re: A Wavy Future

[Yuri Z]

There is at least one commercial successor - https://www.co-meeting.com/
There was also another commercial attempt, which failed but is now open
sourced - https://github.com/jorkey/Wiab.pro

On Fri, Mar 18, 2016 at 12:29 PM Adam Bielski 
wrote:

> Hiya all!
> I am new to this mailing group and I wanted to further understand the
> limitations OR differences that WiaB provides in comparisson to:
>
>
> https://www.crunchbase.com/organization/pie-computing#/entity
>
> And WHY has there not been a successor (based on the GOOGLE WAVE project)
> that has ever been launched for commercial use!?
> Cheers!
> Adam
> 2:29 środa, 2016-3-16, Evan Hughes  napisał(a):
>
>
>
>
> Sorry many mistakes, currently on mobile. Meant to say "the OS editors arnt
> bad but."
> On 16/03/2016 11:18 AM, "Evan Hughes"  wrote:
>
> > I had a look at quill and react seperatly dismorning, interestingly the
> > atom editor is built using react and they have done at least one if not
> > more about how they get more performance out of it, moving rendering to
> the
> > gpu and such.
> >
> > Do you think itll actually be possible to remove ot somewhat from the
> > client,  how do we efficently send data to the client that the document
> has
> > changed.
> >
> > Also we must be very careful abiut what editor we choose if we arnt
> > building one inhouse, debugging could destroy us all.
> >
> > But the c-rendering we could do inhouse then we would have a basis for
> > creating a c-editor from scatch. Not that the OS projects are bad but
> its a
> > pretty broad featire set we need.
> > On 16/03/2016 11:00 AM, "Joseph Gentle"  wrote:
> >
> >> Sorry, just poking in here -
> >>
> >> A couple of years ago I worked with QuillJS's author to add OT to
> >> quill. Its a rich text editor, which emits user events and Jason (the
> >> author) has a module which interprets those events, builds operations
> >> and can do OT with them. It doesn't support rich embedding of
> >> components yet, but he's working on that now.
> >>
> >> React's Draft-js might also work well.
> >>
> >> -J
> >>
> >> On Wed, Mar 16, 2016 at 11:18 AM, Michael MacFadden
> >>  wrote:
> >> > All,
> >> >
> >> > A few things on the editor.  For one.  I think ACE is a plain text
> >> editor, which I have used for a bunch of things.  Has a great API for
> >> collaboration integration, but it is not rich text, which is what wave
> is
> >> all about.  So I don’t think that will work.
> >> >
> >> > Also, I think perhaps I should clarify the term editor.  I probably
> >> used in inappropriately.
> >> >
> >> > There are two parts to be concerned with.  The first is collaborative
> >> rendering.  If you are just looking at a blip, you can still see it
> change
> >> in real time.  So this would be collaborative rendering.  Then when you
> are
> >> actively editing a blip, you need a collaborative editor.  Both are
> >> important.
> >> >
> >> > The main performance issue comes in two places.  First I may have a
> >> conversation model that contains hundreds of blips.  Some sort of lazy
> >> loading strategy here is probably required and smart attaching and
> >> detaching of listeners.  If you have hundreds of blips all rendered at
> once
> >> and all having to have listeners attached to them because any one of
> them
> >> can change at any time you can run into rendering performance issues.
> >> Secondarily, if you do have lots of people editing lots of blips, much
> of
> >> that will not be “on screen” for a given user, and you don’t want to be
> >> processing all of those events and messing with the DOM if you don’t
> need
> >> to.  So there are performance and complexity issues there.
> >> >
> >> > Then there is the actual editor.  Building a Rich Text Editor is not
> >> trivial (still.. How can this be???).  So you have to deal with all the
> >> issues of building a rich text editor.  Then on top of that you want to
> >> integrate remote cursors, selections, authorship, etc. into that editor.
> >> Most editors do not have that (a few do, and some are easier than
> others to
> >> add that).  So there is complexity here as well.
> >> >
> >> > If you want to use an open source editor you need one that does the
> >> kind of rich text editing you want to do. It needs to either have the
> >> collaboration capabilities (shared cursors, etc.) that you want, or it
> has
> >> to be reasonably easy to implement them yourself.  And it needs to have
> a
> >> good enough eventing API for you to hook into it to capture local
> changes,
> >> and to have API to allow you to drive remote changes into it.
> >> >
> >> > The point being that, the conversation renderer and rich text editor
> is
> >> a very non-trivial component, if the assumption is to roughly replicate
> >> what is there.
> >> >
> >> >
> >> > One point I definitely agree with is that the editor itself really
> >> should know nothing 

Re: A Wavy Future

[Thomas Wrobel]

As for the differences to Pie...I cant tell because there seems to be
very little information on Pie online, nor a working copy.
Id guess however Pie is a closed, unfederated messaging system though.
Can previous messages be edited? is the conversation thread
non-linear?
The differences between a wave server/client system and a (typical) "
fun messaging app" would be quite a lot.
--
http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.


On 18 March 2016 at 18:26, Yuri Z  wrote:
> There is at least one commercial successor - https://www.co-meeting.com/
> There was also another commercial attempt, which failed but is now open
> sourced - https://github.com/jorkey/Wiab.pro
>
> On Fri, Mar 18, 2016 at 12:29 PM Adam Bielski 
> wrote:
>
>> Hiya all!
>> I am new to this mailing group and I wanted to further understand the
>> limitations OR differences that WiaB provides in comparisson to:
>>
>>
>> https://www.crunchbase.com/organization/pie-computing#/entity
>>
>> And WHY has there not been a successor (based on the GOOGLE WAVE project)
>> that has ever been launched for commercial use!?
>> Cheers!
>> Adam
>> 2:29 środa, 2016-3-16, Evan Hughes  napisał(a):
>>
>>
>>
>>
>> Sorry many mistakes, currently on mobile. Meant to say "the OS editors arnt
>> bad but."
>> On 16/03/2016 11:18 AM, "Evan Hughes"  wrote:
>>
>> > I had a look at quill and react seperatly dismorning, interestingly the
>> > atom editor is built using react and they have done at least one if not
>> > more about how they get more performance out of it, moving rendering to
>> the
>> > gpu and such.
>> >
>> > Do you think itll actually be possible to remove ot somewhat from the
>> > client,  how do we efficently send data to the client that the document
>> has
>> > changed.
>> >
>> > Also we must be very careful abiut what editor we choose if we arnt
>> > building one inhouse, debugging could destroy us all.
>> >
>> > But the c-rendering we could do inhouse then we would have a basis for
>> > creating a c-editor from scatch. Not that the OS projects are bad but
>> its a
>> > pretty broad featire set we need.
>> > On 16/03/2016 11:00 AM, "Joseph Gentle"  wrote:
>> >
>> >> Sorry, just poking in here -
>> >>
>> >> A couple of years ago I worked with QuillJS's author to add OT to
>> >> quill. Its a rich text editor, which emits user events and Jason (the
>> >> author) has a module which interprets those events, builds operations
>> >> and can do OT with them. It doesn't support rich embedding of
>> >> components yet, but he's working on that now.
>> >>
>> >> React's Draft-js might also work well.
>> >>
>> >> -J
>> >>
>> >> On Wed, Mar 16, 2016 at 11:18 AM, Michael MacFadden
>> >>  wrote:
>> >> > All,
>> >> >
>> >> > A few things on the editor.  For one.  I think ACE is a plain text
>> >> editor, which I have used for a bunch of things.  Has a great API for
>> >> collaboration integration, but it is not rich text, which is what wave
>> is
>> >> all about.  So I don’t think that will work.
>> >> >
>> >> > Also, I think perhaps I should clarify the term editor.  I probably
>> >> used in inappropriately.
>> >> >
>> >> > There are two parts to be concerned with.  The first is collaborative
>> >> rendering.  If you are just looking at a blip, you can still see it
>> change
>> >> in real time.  So this would be collaborative rendering.  Then when you
>> are
>> >> actively editing a blip, you need a collaborative editor.  Both are
>> >> important.
>> >> >
>> >> > The main performance issue comes in two places.  First I may have a
>> >> conversation model that contains hundreds of blips.  Some sort of lazy
>> >> loading strategy here is probably required and smart attaching and
>> >> detaching of listeners.  If you have hundreds of blips all rendered at
>> once
>> >> and all having to have listeners attached to them because any one of
>> them
>> >> can change at any time you can run into rendering performance issues.
>> >> Secondarily, if you do have lots of people editing lots of blips, much
>> of
>> >> that will not be “on screen” for a given user, and you don’t want to be
>> >> processing all of those events and messing with the DOM if you don’t
>> need
>> >> to.  So there are performance and complexity issues there.
>> >> >
>> >> > Then there is the actual editor.  Building a Rich Text Editor is not
>> >> trivial (still.. How can this be???).  So you have to deal with all the
>> >> issues of building a rich text editor.  Then on top of that you want to
>> >> integrate remote cursors, selections, authorship, etc. into that editor.
>> >> Most editors do not have that (a few do, and some are easier than
>> others to
>> >> add that).  So there is complexity here as well.
>> >> >
>> >> > If you want to use an open source editor you need one that does the
>> >> kind of 

Re: A Wavy Future

[Evan Hughes]

Whats the best way we can collab on a protocol spec.

On Sat, 19 Mar 2016 at 07:05 Thomas Wrobel  wrote:

> As for the differences to Pie...I cant tell because there seems to be
> very little information on Pie online, nor a working copy.
> Id guess however Pie is a closed, unfederated messaging system though.
> Can previous messages be edited? is the conversation thread
> non-linear?
> The differences between a wave server/client system and a (typical) "
> fun messaging app" would be quite a lot.
> --
> http://lostagain.nl <-- our company site.
> http://fanficmaker.com <-- our, really,really, bad story generator.
>
>
> On 18 March 2016 at 18:26, Yuri Z  wrote:
> > There is at least one commercial successor - https://www.co-meeting.com/
> > There was also another commercial attempt, which failed but is now open
> > sourced - https://github.com/jorkey/Wiab.pro
> >
> > On Fri, Mar 18, 2016 at 12:29 PM Adam Bielski
> 
> > wrote:
> >
> >> Hiya all!
> >> I am new to this mailing group and I wanted to further understand the
> >> limitations OR differences that WiaB provides in comparisson to:
> >>
> >>
> >> https://www.crunchbase.com/organization/pie-computing#/entity
> >>
> >> And WHY has there not been a successor (based on the GOOGLE WAVE
> project)
> >> that has ever been launched for commercial use!?
> >> Cheers!
> >> Adam
> >> 2:29 środa, 2016-3-16, Evan Hughes  napisał(a):
> >>
> >>
> >>
> >>
> >> Sorry many mistakes, currently on mobile. Meant to say "the OS editors
> arnt
> >> bad but."
> >> On 16/03/2016 11:18 AM, "Evan Hughes"  wrote:
> >>
> >> > I had a look at quill and react seperatly dismorning, interestingly
> the
> >> > atom editor is built using react and they have done at least one if
> not
> >> > more about how they get more performance out of it, moving rendering
> to
> >> the
> >> > gpu and such.
> >> >
> >> > Do you think itll actually be possible to remove ot somewhat from the
> >> > client,  how do we efficently send data to the client that the
> document
> >> has
> >> > changed.
> >> >
> >> > Also we must be very careful abiut what editor we choose if we arnt
> >> > building one inhouse, debugging could destroy us all.
> >> >
> >> > But the c-rendering we could do inhouse then we would have a basis for
> >> > creating a c-editor from scatch. Not that the OS projects are bad but
> >> its a
> >> > pretty broad featire set we need.
> >> > On 16/03/2016 11:00 AM, "Joseph Gentle"  wrote:
> >> >
> >> >> Sorry, just poking in here -
> >> >>
> >> >> A couple of years ago I worked with QuillJS's author to add OT to
> >> >> quill. Its a rich text editor, which emits user events and Jason (the
> >> >> author) has a module which interprets those events, builds operations
> >> >> and can do OT with them. It doesn't support rich embedding of
> >> >> components yet, but he's working on that now.
> >> >>
> >> >> React's Draft-js might also work well.
> >> >>
> >> >> -J
> >> >>
> >> >> On Wed, Mar 16, 2016 at 11:18 AM, Michael MacFadden
> >> >>  wrote:
> >> >> > All,
> >> >> >
> >> >> > A few things on the editor.  For one.  I think ACE is a plain text
> >> >> editor, which I have used for a bunch of things.  Has a great API for
> >> >> collaboration integration, but it is not rich text, which is what
> wave
> >> is
> >> >> all about.  So I don’t think that will work.
> >> >> >
> >> >> > Also, I think perhaps I should clarify the term editor.  I probably
> >> >> used in inappropriately.
> >> >> >
> >> >> > There are two parts to be concerned with.  The first is
> collaborative
> >> >> rendering.  If you are just looking at a blip, you can still see it
> >> change
> >> >> in real time.  So this would be collaborative rendering.  Then when
> you
> >> are
> >> >> actively editing a blip, you need a collaborative editor.  Both are
> >> >> important.
> >> >> >
> >> >> > The main performance issue comes in two places.  First I may have a
> >> >> conversation model that contains hundreds of blips.  Some sort of
> lazy
> >> >> loading strategy here is probably required and smart attaching and
> >> >> detaching of listeners.  If you have hundreds of blips all rendered
> at
> >> once
> >> >> and all having to have listeners attached to them because any one of
> >> them
> >> >> can change at any time you can run into rendering performance issues.
> >> >> Secondarily, if you do have lots of people editing lots of blips,
> much
> >> of
> >> >> that will not be “on screen” for a given user, and you don’t want to
> be
> >> >> processing all of those events and messing with the DOM if you don’t
> >> need
> >> >> to.  So there are performance and complexity issues there.
> >> >> >
> >> >> > Then there is the actual editor.  Building a Rich Text Editor is
> not
> >> >> trivial (still.. How can this be???).  So you have to deal with all
> the
> >> >> issues of 

Re: Speed issues of wiab resolved and open sourced on github

[Yuri Z]

Hi Kirill
Great news, thanks!
I think those were the main issues with Apache Wave. Hopefully your
contributions will allow us to fix those issues and make Apache Wave faster
and more stable.

On Wed, Mar 16, 2016 at 1:59 PM Kirill Kostyuchenko 
wrote:

> Hello developers!
>
> We released our features to github repository
> https://github.com/jorkey/Wiab.pro
>
> The key features is indexed delta storage and new rendering mechanism.
>