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

[Pablo Ojanguren]

Great! thanks a lot! really necessary stuff.

2016-03-16 15:15 GMT+01:00 Michael MacFadden :

> Cool. Is there a current demo of this running some where?
>
> ~Michael
>
>
>
>
> On 3/16/16, 5:01 AM, "Yuri Z"  wrote:
>
> >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.
> >>
>
>

Re: A Wavy Future

[pablojan]

I will be glad to collaborate :)

El 20/3/2016 3:36 a. m., Evan Hughes  escribió:

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.
>>