subject:"A Wavy Future"

A wavy future side project

2016-04-29 Thread Evan Hughes

Hello all,

Just letting you know I have started moving forward with the rewrite
project which MAY NOT become the root source of the incubator. Please see:

https://github.com/apache/incubator-wave/tree/wavy for source,
https://cwiki.apache.org/confluence/display/WAVE/Project+Brief
 for a
description of what the aim of the side project.

The project is mostly gonna focus atm on providing nice documentation and
building up an editor which is not Apache Wave specific. I'm hoping to get
the basis of each of the components in place before end of next week so
that anyone with any skill can contribute to whichever part they choose.

~ Evan Hughes

Re: Wavy Future - Project Brief

2016-04-15 Thread Evan Hughes

Upayavira,

I just noticed you corrected my english ahah.

Thinking about only focusing on the editor atm as this is something the
entire project can use internally and externally.

On Fri, 8 Apr 2016 at 08:21 Upayavira <u...@odoko.co.uk> wrote:

> Not quite a timeline. There can never be a timeline with an open source
> project, because no-one can be held to that timeline. I'm more saying,
> break it down into small enough tasks to create things that are
> objectively useful of themselves in manageable amounts of time. That
> way, we'll draw in developers who want to use those bits, and are
> interested in adding more.
>
> Open source development does not work the same as commercial
> development, as the motivations are entirely different. My boss can tell
> me I must write something I really don't want to, but it doesn't work
> that way in open source - the project has no power to make me do
> anything at all, in which case, timescales are pretty useless.
>
> Upayavira
>
> On Thu, 7 Apr 2016, at 10:37 PM, Gaurav Shukla wrote:
> > I second Upayavira on this, the project brief looks fine but it should be
> > broken down into meaningful sub tasks with a proper timeline.
> >
> >
> >
> >
> >
> >
> > Sent with MailTrack
> > <
> https://mailtrack.io/install?source=signature=en=gshukl...@gmail.com=22
> >
> >
> > On Fri, Apr 8, 2016 at 12:40 AM, Upayavira <u...@odoko.co.uk> wrote:
> >
> > >
> > >
> > > On Thu, 7 Apr 2016, at 07:08 AM, Evan Hughes wrote:
> > > > Hello all,
> > > >
> > > > This is a project brief that some new interested developers asked
> for,
> > > > please note that* this is for the Apache Wave rewrite *project "A
> Wavy
> > > > Future" due to the potential of the rewrite not being the main
> source and
> > > > not for the current source which exists in the repo.
> > > >
> > > > https://cwiki.apache.org/confluence/display/WAVE/Project+Brief
> > > >
> > > > Please feel free to give feedback either here or on the document if
> you
> > > > have an account. Also note that some sections of the document are
> > > > unfinished like the timeline.
> > >
> > > Evan,
> > >
> > > You are presenting something pretty monolithic - it could be hard to
> get
> > > a group of developers to work together on such a large endeavour.
> > >
> > > Can you break it down into smaller pieces, each of which are useful in
> > > themselves? If you can present something like, "here is an OT engine
> > > that can be used by any project, and will take 1mth to develop", then
> > > you have something distinctly useful, and something that is much more
> > > likely to draw in new developers, because the project HAS something
> they
> > > can immediately use.
> > >
> > > The best way to develop open source is to tap into developer's sense of
> > > their own self-interest.
> > >
> > > Thoughts?
> > >
> > > Upayavira
> > >
> >
> >
> >
> > --
> > Regards !
> > Gaurav Shukla
> > gauravshukla.xyz
>

Re: Wavy Future - Project Brief

2016-04-07 Thread Upayavira

Not quite a timeline. There can never be a timeline with an open source
project, because no-one can be held to that timeline. I'm more saying,
break it down into small enough tasks to create things that are
objectively useful of themselves in manageable amounts of time. That
way, we'll draw in developers who want to use those bits, and are
interested in adding more.

Open source development does not work the same as commercial
development, as the motivations are entirely different. My boss can tell
me I must write something I really don't want to, but it doesn't work
that way in open source - the project has no power to make me do
anything at all, in which case, timescales are pretty useless.

Upayavira

On Thu, 7 Apr 2016, at 10:37 PM, Gaurav Shukla wrote:
> I second Upayavira on this, the project brief looks fine but it should be
> broken down into meaningful sub tasks with a proper timeline.
> 
> 
> 
> 
> 
> 
> Sent with MailTrack
> <https://mailtrack.io/install?source=signature=en=gshukl...@gmail.com=22>
> 
> On Fri, Apr 8, 2016 at 12:40 AM, Upayavira <u...@odoko.co.uk> wrote:
> 
> >
> >
> > On Thu, 7 Apr 2016, at 07:08 AM, Evan Hughes wrote:
> > > Hello all,
> > >
> > > This is a project brief that some new interested developers asked for,
> > > please note that* this is for the Apache Wave rewrite *project "A Wavy
> > > Future" due to the potential of the rewrite not being the main source and
> > > not for the current source which exists in the repo.
> > >
> > > https://cwiki.apache.org/confluence/display/WAVE/Project+Brief
> > >
> > > Please feel free to give feedback either here or on the document if you
> > > have an account. Also note that some sections of the document are
> > > unfinished like the timeline.
> >
> > Evan,
> >
> > You are presenting something pretty monolithic - it could be hard to get
> > a group of developers to work together on such a large endeavour.
> >
> > Can you break it down into smaller pieces, each of which are useful in
> > themselves? If you can present something like, "here is an OT engine
> > that can be used by any project, and will take 1mth to develop", then
> > you have something distinctly useful, and something that is much more
> > likely to draw in new developers, because the project HAS something they
> > can immediately use.
> >
> > The best way to develop open source is to tap into developer's sense of
> > their own self-interest.
> >
> > Thoughts?
> >
> > Upayavira
> >
> 
> 
> 
> -- 
> Regards !
> Gaurav Shukla
> gauravshukla.xyz

Re: Wavy Future - Project Brief

2016-04-07 Thread Gaurav Shukla

I second Upayavira on this, the project brief looks fine but it should be
broken down into meaningful sub tasks with a proper timeline.






Sent with MailTrack
<https://mailtrack.io/install?source=signature=en=gshukl...@gmail.com=22>

On Fri, Apr 8, 2016 at 12:40 AM, Upayavira <u...@odoko.co.uk> wrote:

>
>
> On Thu, 7 Apr 2016, at 07:08 AM, Evan Hughes wrote:
> > Hello all,
> >
> > This is a project brief that some new interested developers asked for,
> > please note that* this is for the Apache Wave rewrite *project "A Wavy
> > Future" due to the potential of the rewrite not being the main source and
> > not for the current source which exists in the repo.
> >
> > https://cwiki.apache.org/confluence/display/WAVE/Project+Brief
> >
> > Please feel free to give feedback either here or on the document if you
> > have an account. Also note that some sections of the document are
> > unfinished like the timeline.
>
> Evan,
>
> You are presenting something pretty monolithic - it could be hard to get
> a group of developers to work together on such a large endeavour.
>
> Can you break it down into smaller pieces, each of which are useful in
> themselves? If you can present something like, "here is an OT engine
> that can be used by any project, and will take 1mth to develop", then
> you have something distinctly useful, and something that is much more
> likely to draw in new developers, because the project HAS something they
> can immediately use.
>
> The best way to develop open source is to tap into developer's sense of
> their own self-interest.
>
> Thoughts?
>
> Upayavira
>



-- 
Regards !
Gaurav Shukla
gauravshukla.xyz

Re: Wavy Future - Project Brief

2016-04-07 Thread Upayavira

On Thu, 7 Apr 2016, at 07:08 AM, Evan Hughes wrote:
> Hello all,
> 
> This is a project brief that some new interested developers asked for,
> please note that* this is for the Apache Wave rewrite *project "A Wavy
> Future" due to the potential of the rewrite not being the main source and
> not for the current source which exists in the repo.
> 
> https://cwiki.apache.org/confluence/display/WAVE/Project+Brief
> 
> Please feel free to give feedback either here or on the document if you
> have an account. Also note that some sections of the document are
> unfinished like the timeline.

Evan,

You are presenting something pretty monolithic - it could be hard to get
a group of developers to work together on such a large endeavour.

Can you break it down into smaller pieces, each of which are useful in
themselves? If you can present something like, "here is an OT engine
that can be used by any project, and will take 1mth to develop", then
you have something distinctly useful, and something that is much more
likely to draw in new developers, because the project HAS something they
can immediately use.

The best way to develop open source is to tap into developer's sense of
their own self-interest.

Thoughts?

Upayavira

Re: A Wavy Future

2016-03-20 Thread 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.
>>

Re: A Wavy Future

2016-03-19 Thread 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

Re: A Wavy Future

2016-03-19 Thread 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

2016-03-19 Thread 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

2016-03-19 Thread 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

2016-03-19 Thread 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: A Wavy Future

2016-03-18 Thread Adam Bielski

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 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 from mozilla,
>> >>https://en.wikipedia.org/wiki/Ace_%28editor%29
>> >>
>> >>BTW, as example, this is an app we are developing on with SwellRT as
>> >>backend:  http://staging.teem.works , -it is the staging version, you
>> can
>> >>play! ;)-

Re: A Wavy Future

2016-03-15 Thread Evan Hughes

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 from mozilla,
>> >>https://en.wikipedia.org/wiki/Ace_%28editor%29
>> >>
>> >>BTW, as example, this is an app we are developing on with SwellRT as
>> >>backend:  http://staging.teem.works , -it is the staging version, you
>> can
>> >>play! ;)-
>> >>
>> >>2016-03-15 17:12 GMT+01:00 Yuri Z :
>> >>
>> >>> No, not really. Javascript on client side is enough - this is how it
>> was
>> >>> originally implemented in microwave by antimatter.
>> >>>
>> >>> On Tue, Mar 15, 2016 at 6:08 PM Thomas Wrobel 
>> wrote:
>> >>>
>> >>> > Ah, right. I am all for realtime, merely that I was also happy to
>> lose
>> >>> > it if it meant

Re: A Wavy Future

2016-03-15 Thread Evan Hughes

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 from mozilla,
> >>https://en.wikipedia.org/wiki/Ace_%28editor%29
> >>
> >>BTW, as example, this is an app we are developing on with SwellRT as
> >>backend:  http://staging.teem.works , -it is the staging version, you
> can
> >>play! ;)-
> >>
> >>2016-03-15 17:12 GMT+01:00 Yuri Z :
> >>
> >>> No, not really. Javascript on client side is enough - this is how it
> was
> >>> originally implemented in microwave by antimatter.
> >>>
> >>> On Tue, Mar 15, 2016 at 6:08 PM Thomas Wrobel 
> wrote:
> >>>
> >>> > Ah, right. I am all for realtime, merely that I was also happy to
> lose
> >>> > it if it meant significantly more simple implementation.
> >>> >
> >>> > >>"Otherwise we can use Robot
> >>> > >>API - like in https://github.com/vega113/microbox;
> >>> >
> >>> > Not keen on RobotAPI as every time I read its use it seems to need an
> >>> > extra server in the chain/
> >>> > ie;

Re: A Wavy Future

2016-03-15 Thread Joseph Gentle

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 from mozilla,
>>https://en.wikipedia.org/wiki/Ace_%28editor%29
>>
>>BTW, as example, this is an app we are developing on with SwellRT as
>>backend:  http://staging.teem.works , -it is the staging version, you can
>>play! ;)-
>>
>>2016-03-15 17:12 GMT+01:00 Yuri Z :
>>
>>> No, not really. Javascript on client side is enough - this is how it was
>>> originally implemented in microwave by antimatter.
>>>
>>> On Tue, Mar 15, 2016 at 6:08 PM Thomas Wrobel  wrote:
>>>
>>> > Ah, right. I am all for realtime, merely that I was also happy to lose
>>> > it if it meant significantly more simple implementation.
>>> >
>>> > >>"Otherwise we can use Robot
>>> > >>API - like in https://github.com/vega113/microbox;
>>> >
>>> > Not keen on RobotAPI as every time I read its use it seems to need an
>>> > extra server in the chain/
>>> > ie;
>>> >  ...<>WaveServer <> Google App Engine <> client
>>> >
>>> > It should be possible with the web today to avoid that and have
>>> > clients connect directly to the wave server no? (hopefully using the
>>> > same protocol as any desktop/mobile client).
>>> > Of course, I assume you could run host both servers on the same
>>> > hardware, but still seems unnecessary to have that extra step.
>>> >
>>> >
>>> > --
>>> > http://lostagain.nl <-- our company site.
>>> > http://fanficmaker.com <-- our, really,really, bad story generator.
>>> >
>>> >
>>> > On 15 March 2016 at 16:48, Yuri Z  wrote:
>>> > > Yeah, the intention is to have realtime editing. Otherwise we can use
>>> > Robot
>>> > > API - like in https://github.com/vega113/microbox
>>> > >
>>> > > On Tue, Mar 15, 2016 at 5:45 PM Thomas Wrobel 
>>> > wrote:

Re: A Wavy Future

2016-03-15 Thread Michael MacFadden

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 from mozilla,
>https://en.wikipedia.org/wiki/Ace_%28editor%29
>
>BTW, as example, this is an app we are developing on with SwellRT as
>backend:  http://staging.teem.works , -it is the staging version, you can
>play! ;)-
>
>2016-03-15 17:12 GMT+01:00 Yuri Z :
>
>> No, not really. Javascript on client side is enough - this is how it was
>> originally implemented in microwave by antimatter.
>>
>> On Tue, Mar 15, 2016 at 6:08 PM Thomas Wrobel  wrote:
>>
>> > Ah, right. I am all for realtime, merely that I was also happy to lose
>> > it if it meant significantly more simple implementation.
>> >
>> > >>"Otherwise we can use Robot
>> > >>API - like in https://github.com/vega113/microbox;
>> >
>> > Not keen on RobotAPI as every time I read its use it seems to need an
>> > extra server in the chain/
>> > ie;
>> >  ...<>WaveServer <> Google App Engine <> client
>> >
>> > It should be possible with the web today to avoid that and have
>> > clients connect directly to the wave server no? (hopefully using the
>> > same protocol as any desktop/mobile client).
>> > Of course, I assume you could run host both servers on the same
>> > hardware, but still seems unnecessary to have that extra step.
>> >
>> >
>> > --
>> > http://lostagain.nl <-- our company site.
>> > http://fanficmaker.com <-- our, really,really, bad story generator.
>> >
>> >
>> > On 15 March 2016 at 16:48, Yuri Z  wrote:
>> > > Yeah, the intention is to have realtime editing. Otherwise we can use
>> > Robot
>> > > API - like in https://github.com/vega113/microbox
>> > >
>> > > On Tue, Mar 15, 2016 at 5:45 PM Thomas Wrobel 
>> > wrote:
>> > >
>> > >> Does it need to be OT aware on that scale? I thought that was only
>> > >> needed to have fully realtime blip updating rather then a "edit +
>> > >> submit" system. (whereupon the differences could be calculated
>> > >> separately from the editing)
>> > >> Is the intention then to still have realtime editing ? or is this
>> > >> needed anyway regardless?
>> > >>
>> > >> I admit I only know the basics of OT and am vaguely remembering a
>> > >> conversation about realtime blip editing adding complexity to things.
>> > >>
>> > >> --
>> > >> http://lostagain.nl <-- our company site.
>> > >>

Re: A Wavy Future

2016-03-15 Thread Evan Hughes

well people learning how to implement an OT editor wouldnt be the worst
thing in the world ;), specially since if we want to extend to mobile
platforms.

Seems like there's some debate about the way to deal with the code debt but
most people seem onboard with documenting a client-server api/spec?

On Wed, 16 Mar 2016 at 03:12 Pablo Ojanguren  wrote:

> Talking about editors I suggest ace from mozilla,
> https://en.wikipedia.org/wiki/Ace_%28editor%29
>
> BTW, as example, this is an app we are developing on with SwellRT as
> backend:  http://staging.teem.works , -it is the staging version, you can
> play! ;)-
>
> 2016-03-15 17:12 GMT+01:00 Yuri Z :
>
> > No, not really. Javascript on client side is enough - this is how it was
> > originally implemented in microwave by antimatter.
> >
> > On Tue, Mar 15, 2016 at 6:08 PM Thomas Wrobel 
> wrote:
> >
> > > Ah, right. I am all for realtime, merely that I was also happy to lose
> > > it if it meant significantly more simple implementation.
> > >
> > > >>"Otherwise we can use Robot
> > > >>API - like in https://github.com/vega113/microbox;
> > >
> > > Not keen on RobotAPI as every time I read its use it seems to need an
> > > extra server in the chain/
> > > ie;
> > >  ...<>WaveServer <> Google App Engine <> client
> > >
> > > It should be possible with the web today to avoid that and have
> > > clients connect directly to the wave server no? (hopefully using the
> > > same protocol as any desktop/mobile client).
> > > Of course, I assume you could run host both servers on the same
> > > hardware, but still seems unnecessary to have that extra step.
> > >
> > >
> > > --
> > > http://lostagain.nl <-- our company site.
> > > http://fanficmaker.com <-- our, really,really, bad story generator.
> > >
> > >
> > > On 15 March 2016 at 16:48, Yuri Z  wrote:
> > > > Yeah, the intention is to have realtime editing. Otherwise we can use
> > > Robot
> > > > API - like in https://github.com/vega113/microbox
> > > >
> > > > On Tue, Mar 15, 2016 at 5:45 PM Thomas Wrobel 
> > > wrote:
> > > >
> > > >> Does it need to be OT aware on that scale? I thought that was only
> > > >> needed to have fully realtime blip updating rather then a "edit +
> > > >> submit" system. (whereupon the differences could be calculated
> > > >> separately from the editing)
> > > >> Is the intention then to still have realtime editing ? or is this
> > > >> needed anyway regardless?
> > > >>
> > > >> I admit I only know the basics of OT and am vaguely remembering a
> > > >> conversation about realtime blip editing adding complexity to
> things.
> > > >>
> > > >> --
> > > >> http://lostagain.nl <-- our company site.
> > > >> http://fanficmaker.com <-- our, really,really, bad story generator.
> > > >>
> > > >>
> > > >> On 15 March 2016 at 16:30, Yuri Z  wrote:
> > > >> > Not really. You would need to make it OT aware. and then make it
> > > >> efficient.
> > > >> > Lot's of effort.
> > > >> >
> > > >> > On Tue, Mar 15, 2016 at 5:24 PM Thomas Wrobel <
> darkfl...@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> >> As a side, I noticed Michael MacFadden mentioned building a rich
> > text
> > > >> >> editor in the browser, this much at least have been done in GWT
> > > >> >> libraries;
> > > >> >>
> > > >> >>
> > > >>
> > >
> >
> http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/ui/RichTextArea.html
> > > >> >>
> > > >> >> Its fairly basic, but then, I would assume to start with at least
> > any
> > > >> >> new wave client should stay fairly basic?
> > > >> >> --
> > > >> >> http://lostagain.nl <-- our company site.
> > > >> >> http://fanficmaker.com <-- our, really,really, bad story
> > generator.
> > > >> >>
> > > >> >>
> > > >> >> On 15 March 2016 at 15:48, Yuri Z  wrote:
> > > >> >> > Yeah, we need to re-use the existing editor. Patches would be
> > > great!
> > > >> >> >
> > > >> >> > On Tue, Mar 15, 2016 at 4:46 PM Pablo Ojanguren <
> > > pablo...@gmail.com>
> > > >> >> wrote:
> > > >> >> >
> > > >> >> >> Hi,
> > > >> >> >>
> > > >> >> >> I agree with the dependency hell issue and the suggestion for
> > > >> throwing
> > > >> >> >> away the GWT client. This would require a new client-server
> API
> > as
> > > >> >> >> suggested, however I think a Rest API won't be enough, because
> > > real
> > > >> >> editing
> > > >> >> >> needs websocket.
> > > >> >> >>
> > > >> >> >> I also agree with Michael, developing a new editor is a
> massive
> > > >> task, so
> > > >> >> >> we should use an existing one and plug it in the new API.
> > > >> >> >>
> > > >> >> >> To write again the server in other language would be great,
> but
> > I
> > > >> think
> > > >> >> it
> > > >> >> >> requires a huge effort.
> > > >> >> >>
> > > >> >> >> I will be happy to help in decoupling the server-client, I can
> > > >> provide
> > > >> >> the
> > > >> >> >> experience from my fork.

Re: A Wavy Future

2016-03-15 Thread Pablo Ojanguren

Talking about editors I suggest ace from mozilla,
https://en.wikipedia.org/wiki/Ace_%28editor%29

BTW, as example, this is an app we are developing on with SwellRT as
backend:  http://staging.teem.works , -it is the staging version, you can
play! ;)-

2016-03-15 17:12 GMT+01:00 Yuri Z :

> No, not really. Javascript on client side is enough - this is how it was
> originally implemented in microwave by antimatter.
>
> On Tue, Mar 15, 2016 at 6:08 PM Thomas Wrobel  wrote:
>
> > Ah, right. I am all for realtime, merely that I was also happy to lose
> > it if it meant significantly more simple implementation.
> >
> > >>"Otherwise we can use Robot
> > >>API - like in https://github.com/vega113/microbox;
> >
> > Not keen on RobotAPI as every time I read its use it seems to need an
> > extra server in the chain/
> > ie;
> >  ...<>WaveServer <> Google App Engine <> client
> >
> > It should be possible with the web today to avoid that and have
> > clients connect directly to the wave server no? (hopefully using the
> > same protocol as any desktop/mobile client).
> > Of course, I assume you could run host both servers on the same
> > hardware, but still seems unnecessary to have that extra step.
> >
> >
> > --
> > http://lostagain.nl <-- our company site.
> > http://fanficmaker.com <-- our, really,really, bad story generator.
> >
> >
> > On 15 March 2016 at 16:48, Yuri Z  wrote:
> > > Yeah, the intention is to have realtime editing. Otherwise we can use
> > Robot
> > > API - like in https://github.com/vega113/microbox
> > >
> > > On Tue, Mar 15, 2016 at 5:45 PM Thomas Wrobel 
> > wrote:
> > >
> > >> Does it need to be OT aware on that scale? I thought that was only
> > >> needed to have fully realtime blip updating rather then a "edit +
> > >> submit" system. (whereupon the differences could be calculated
> > >> separately from the editing)
> > >> Is the intention then to still have realtime editing ? or is this
> > >> needed anyway regardless?
> > >>
> > >> I admit I only know the basics of OT and am vaguely remembering a
> > >> conversation about realtime blip editing adding complexity to things.
> > >>
> > >> --
> > >> http://lostagain.nl <-- our company site.
> > >> http://fanficmaker.com <-- our, really,really, bad story generator.
> > >>
> > >>
> > >> On 15 March 2016 at 16:30, Yuri Z  wrote:
> > >> > Not really. You would need to make it OT aware. and then make it
> > >> efficient.
> > >> > Lot's of effort.
> > >> >
> > >> > On Tue, Mar 15, 2016 at 5:24 PM Thomas Wrobel 
> > >> wrote:
> > >> >
> > >> >> As a side, I noticed Michael MacFadden mentioned building a rich
> text
> > >> >> editor in the browser, this much at least have been done in GWT
> > >> >> libraries;
> > >> >>
> > >> >>
> > >>
> >
> http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/ui/RichTextArea.html
> > >> >>
> > >> >> Its fairly basic, but then, I would assume to start with at least
> any
> > >> >> new wave client should stay fairly basic?
> > >> >> --
> > >> >> http://lostagain.nl <-- our company site.
> > >> >> http://fanficmaker.com <-- our, really,really, bad story
> generator.
> > >> >>
> > >> >>
> > >> >> On 15 March 2016 at 15:48, Yuri Z  wrote:
> > >> >> > Yeah, we need to re-use the existing editor. Patches would be
> > great!
> > >> >> >
> > >> >> > On Tue, Mar 15, 2016 at 4:46 PM Pablo Ojanguren <
> > pablo...@gmail.com>
> > >> >> wrote:
> > >> >> >
> > >> >> >> Hi,
> > >> >> >>
> > >> >> >> I agree with the dependency hell issue and the suggestion for
> > >> throwing
> > >> >> >> away the GWT client. This would require a new client-server API
> as
> > >> >> >> suggested, however I think a Rest API won't be enough, because
> > real
> > >> >> editing
> > >> >> >> needs websocket.
> > >> >> >>
> > >> >> >> I also agree with Michael, developing a new editor is a massive
> > >> task, so
> > >> >> >> we should use an existing one and plug it in the new API.
> > >> >> >>
> > >> >> >> To write again the server in other language would be great, but
> I
> > >> think
> > >> >> it
> > >> >> >> requires a huge effort.
> > >> >> >>
> > >> >> >> I will be happy to help in decoupling the server-client, I can
> > >> provide
> > >> >> the
> > >> >> >> experience from my fork. And I plan to send some patches to Wave
> > >> soon.
> > >> >> >>
> > >> >> >>
> > >> >> >> These are some slides about my fork (swellrt) it could give you
> > some
> > >> >> ideas:
> > >> >> >>
> > >> >> >>
> > >> >>
> > >>
> >
> https://docs.google.com/presentation/d/1WFDS_m7eyNjBjcdPs0zH496Y9bMSl0_JnSEYGjxNFn0/edit?usp=sharing
> > >> >> >>
> > >> >> >>
> > >> >>
> > >>
> >
> https://docs.google.com/presentation/d/18hMYyECo5EmQsrAb8DT6SkO7LksWVJnhdZmqeCsar4c/edit?usp=sharing
> > >> >> >>
> > >> >> >> btw, I would like to start a business providing these SwellRT
> > >> services.
> > >> >> >>
> > >> >> >>
> > >> >>

Re: A Wavy Future

2016-03-15 Thread Thomas Wrobel

Ah, right. I am all for realtime, merely that I was also happy to lose
it if it meant significantly more simple implementation.

>>"Otherwise we can use Robot
>>API - like in https://github.com/vega113/microbox;

Not keen on RobotAPI as every time I read its use it seems to need an
extra server in the chain/
ie;
 ...<>WaveServer <> Google App Engine <> client

It should be possible with the web today to avoid that and have
clients connect directly to the wave server no? (hopefully using the
same protocol as any desktop/mobile client).
Of course, I assume you could run host both servers on the same
hardware, but still seems unnecessary to have that extra step.


--
http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.


On 15 March 2016 at 16:48, Yuri Z  wrote:
> Yeah, the intention is to have realtime editing. Otherwise we can use Robot
> API - like in https://github.com/vega113/microbox
>
> On Tue, Mar 15, 2016 at 5:45 PM Thomas Wrobel  wrote:
>
>> Does it need to be OT aware on that scale? I thought that was only
>> needed to have fully realtime blip updating rather then a "edit +
>> submit" system. (whereupon the differences could be calculated
>> separately from the editing)
>> Is the intention then to still have realtime editing ? or is this
>> needed anyway regardless?
>>
>> I admit I only know the basics of OT and am vaguely remembering a
>> conversation about realtime blip editing adding complexity to things.
>>
>> --
>> http://lostagain.nl <-- our company site.
>> http://fanficmaker.com <-- our, really,really, bad story generator.
>>
>>
>> On 15 March 2016 at 16:30, Yuri Z  wrote:
>> > Not really. You would need to make it OT aware. and then make it
>> efficient.
>> > Lot's of effort.
>> >
>> > On Tue, Mar 15, 2016 at 5:24 PM Thomas Wrobel 
>> wrote:
>> >
>> >> As a side, I noticed Michael MacFadden mentioned building a rich text
>> >> editor in the browser, this much at least have been done in GWT
>> >> libraries;
>> >>
>> >>
>> http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/ui/RichTextArea.html
>> >>
>> >> Its fairly basic, but then, I would assume to start with at least any
>> >> new wave client should stay fairly basic?
>> >> --
>> >> http://lostagain.nl <-- our company site.
>> >> http://fanficmaker.com <-- our, really,really, bad story generator.
>> >>
>> >>
>> >> On 15 March 2016 at 15:48, Yuri Z  wrote:
>> >> > Yeah, we need to re-use the existing editor. Patches would be great!
>> >> >
>> >> > On Tue, Mar 15, 2016 at 4:46 PM Pablo Ojanguren 
>> >> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> I agree with the dependency hell issue and the suggestion for
>> throwing
>> >> >> away the GWT client. This would require a new client-server API as
>> >> >> suggested, however I think a Rest API won't be enough, because real
>> >> editing
>> >> >> needs websocket.
>> >> >>
>> >> >> I also agree with Michael, developing a new editor is a massive
>> task, so
>> >> >> we should use an existing one and plug it in the new API.
>> >> >>
>> >> >> To write again the server in other language would be great, but I
>> think
>> >> it
>> >> >> requires a huge effort.
>> >> >>
>> >> >> I will be happy to help in decoupling the server-client, I can
>> provide
>> >> the
>> >> >> experience from my fork. And I plan to send some patches to Wave
>> soon.
>> >> >>
>> >> >>
>> >> >> These are some slides about my fork (swellrt) it could give you some
>> >> ideas:
>> >> >>
>> >> >>
>> >>
>> https://docs.google.com/presentation/d/1WFDS_m7eyNjBjcdPs0zH496Y9bMSl0_JnSEYGjxNFn0/edit?usp=sharing
>> >> >>
>> >> >>
>> >>
>> https://docs.google.com/presentation/d/18hMYyECo5EmQsrAb8DT6SkO7LksWVJnhdZmqeCsar4c/edit?usp=sharing
>> >> >>
>> >> >> btw, I would like to start a business providing these SwellRT
>> services.
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2016-03-14 23:27 GMT+01:00 Joseph Gentle :
>> >> >>
>> >> >>> I've been playing with the idea of starting a company around a
>> rewrite
>> >> of
>> >> >>> wave for years.
>> >> >>>
>> >> >>> -J
>> >> >>>
>> >> >>> On Tuesday, 15 March 2016, Adam Bielski > >
>> >> >>> wrote:
>> >> >>>
>> >> >>> > Hiya all!I wish I could find out who is potentially interested in
>> >> >>> creating
>> >> >>> > the WAVE for a commercial service/productwith my seed
>> startup!Cheers!
>> >> >>> > Adam
>> >> >>> >
>> >> >>> > 20:23 poniedziałek, 2016-3-14, Zachary Yaro > >> >>> > > napisał(a):
>> >> >>> >
>> >> >>> >
>> >> >>> >  I am inclined to agree with Yuri—if the alternative
>> implementation
>> >> can
>> >> >>> be
>> >> >>> > developed in parallel around the same protocol, that would seem
>> to be
>> >> >>> the
>> >> >>> > best scenario, but the existing codebase should be kept because
>> it is
>> >> >>> > (AFAIK) the most

Re: A Wavy Future

2016-03-15 Thread Yuri Z

Yeah, the intention is to have realtime editing. Otherwise we can use Robot
API - like in https://github.com/vega113/microbox

On Tue, Mar 15, 2016 at 5:45 PM Thomas Wrobel  wrote:

> Does it need to be OT aware on that scale? I thought that was only
> needed to have fully realtime blip updating rather then a "edit +
> submit" system. (whereupon the differences could be calculated
> separately from the editing)
> Is the intention then to still have realtime editing ? or is this
> needed anyway regardless?
>
> I admit I only know the basics of OT and am vaguely remembering a
> conversation about realtime blip editing adding complexity to things.
>
> --
> http://lostagain.nl <-- our company site.
> http://fanficmaker.com <-- our, really,really, bad story generator.
>
>
> On 15 March 2016 at 16:30, Yuri Z  wrote:
> > Not really. You would need to make it OT aware. and then make it
> efficient.
> > Lot's of effort.
> >
> > On Tue, Mar 15, 2016 at 5:24 PM Thomas Wrobel 
> wrote:
> >
> >> As a side, I noticed Michael MacFadden mentioned building a rich text
> >> editor in the browser, this much at least have been done in GWT
> >> libraries;
> >>
> >>
> http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/ui/RichTextArea.html
> >>
> >> Its fairly basic, but then, I would assume to start with at least any
> >> new wave client should stay fairly basic?
> >> --
> >> http://lostagain.nl <-- our company site.
> >> http://fanficmaker.com <-- our, really,really, bad story generator.
> >>
> >>
> >> On 15 March 2016 at 15:48, Yuri Z  wrote:
> >> > Yeah, we need to re-use the existing editor. Patches would be great!
> >> >
> >> > On Tue, Mar 15, 2016 at 4:46 PM Pablo Ojanguren 
> >> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I agree with the dependency hell issue and the suggestion for
> throwing
> >> >> away the GWT client. This would require a new client-server API as
> >> >> suggested, however I think a Rest API won't be enough, because real
> >> editing
> >> >> needs websocket.
> >> >>
> >> >> I also agree with Michael, developing a new editor is a massive
> task, so
> >> >> we should use an existing one and plug it in the new API.
> >> >>
> >> >> To write again the server in other language would be great, but I
> think
> >> it
> >> >> requires a huge effort.
> >> >>
> >> >> I will be happy to help in decoupling the server-client, I can
> provide
> >> the
> >> >> experience from my fork. And I plan to send some patches to Wave
> soon.
> >> >>
> >> >>
> >> >> These are some slides about my fork (swellrt) it could give you some
> >> ideas:
> >> >>
> >> >>
> >>
> https://docs.google.com/presentation/d/1WFDS_m7eyNjBjcdPs0zH496Y9bMSl0_JnSEYGjxNFn0/edit?usp=sharing
> >> >>
> >> >>
> >>
> https://docs.google.com/presentation/d/18hMYyECo5EmQsrAb8DT6SkO7LksWVJnhdZmqeCsar4c/edit?usp=sharing
> >> >>
> >> >> btw, I would like to start a business providing these SwellRT
> services.
> >> >>
> >> >>
> >> >>
> >> >> 2016-03-14 23:27 GMT+01:00 Joseph Gentle :
> >> >>
> >> >>> I've been playing with the idea of starting a company around a
> rewrite
> >> of
> >> >>> wave for years.
> >> >>>
> >> >>> -J
> >> >>>
> >> >>> On Tuesday, 15 March 2016, Adam Bielski  >
> >> >>> wrote:
> >> >>>
> >> >>> > Hiya all!I wish I could find out who is potentially interested in
> >> >>> creating
> >> >>> > the WAVE for a commercial service/productwith my seed
> startup!Cheers!
> >> >>> > Adam
> >> >>> >
> >> >>> > 20:23 poniedziałek, 2016-3-14, Zachary Yaro  >> >>> > > napisał(a):
> >> >>> >
> >> >>> >
> >> >>> >  I am inclined to agree with Yuri—if the alternative
> implementation
> >> can
> >> >>> be
> >> >>> > developed in parallel around the same protocol, that would seem
> to be
> >> >>> the
> >> >>> > best scenario, but the existing codebase should be kept because
> it is
> >> >>> > (AFAIK) the most functional implementation of the protocol.
> >> >>> >
> >> >>> > Zachary Yaro
> >> >>> > On Mar 14, 2016 15:05, "Yuri Z"  >
> >> >>> wrote:
> >> >>> >
> >> >>> > > I think that more "wavy" projects are nice, but IMO it doesn't
> >> mean we
> >> >>> > > should abandon Apache Wave as it is now. I agree there are a
> lot of
> >> >>> > issues
> >> >>> > > with current code, but I think there's still value as people can
> >> see
> >> >>> what
> >> >>> > > Wave can potentially be.
> >> >>> > >
> >> >>> > > On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes <
> >> wisebald...@apache.org
> >> >>> > >
> >> >>> > > wrote:
> >> >>> > >
> >> >>> > > > The link for those who wish to join, Ill also add this link
> onto
> >> the
> >> >>> > new
> >> >>> > > > website.
> >> >>> > > >
> >> >>> > > > https://www.hipchat.com/gsModF8CY
> >> >>> > > >
> >> >>> > > > On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
> >> >>> > > >

Re: A Wavy Future

2016-03-15 Thread Yuri Z

Not really. You would need to make it OT aware. and then make it efficient.
Lot's of effort.

On Tue, Mar 15, 2016 at 5:24 PM Thomas Wrobel  wrote:

> As a side, I noticed Michael MacFadden mentioned building a rich text
> editor in the browser, this much at least have been done in GWT
> libraries;
>
> http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/ui/RichTextArea.html
>
> Its fairly basic, but then, I would assume to start with at least any
> new wave client should stay fairly basic?
> --
> http://lostagain.nl <-- our company site.
> http://fanficmaker.com <-- our, really,really, bad story generator.
>
>
> On 15 March 2016 at 15:48, Yuri Z  wrote:
> > Yeah, we need to re-use the existing editor. Patches would be great!
> >
> > On Tue, Mar 15, 2016 at 4:46 PM Pablo Ojanguren 
> wrote:
> >
> >> Hi,
> >>
> >> I agree with the dependency hell issue and the suggestion for throwing
> >> away the GWT client. This would require a new client-server API as
> >> suggested, however I think a Rest API won't be enough, because real
> editing
> >> needs websocket.
> >>
> >> I also agree with Michael, developing a new editor is a massive task, so
> >> we should use an existing one and plug it in the new API.
> >>
> >> To write again the server in other language would be great, but I think
> it
> >> requires a huge effort.
> >>
> >> I will be happy to help in decoupling the server-client, I can provide
> the
> >> experience from my fork. And I plan to send some patches to Wave soon.
> >>
> >>
> >> These are some slides about my fork (swellrt) it could give you some
> ideas:
> >>
> >>
> https://docs.google.com/presentation/d/1WFDS_m7eyNjBjcdPs0zH496Y9bMSl0_JnSEYGjxNFn0/edit?usp=sharing
> >>
> >>
> https://docs.google.com/presentation/d/18hMYyECo5EmQsrAb8DT6SkO7LksWVJnhdZmqeCsar4c/edit?usp=sharing
> >>
> >> btw, I would like to start a business providing these SwellRT services.
> >>
> >>
> >>
> >> 2016-03-14 23:27 GMT+01:00 Joseph Gentle :
> >>
> >>> I've been playing with the idea of starting a company around a rewrite
> of
> >>> wave for years.
> >>>
> >>> -J
> >>>
> >>> On Tuesday, 15 March 2016, Adam Bielski 
> >>> wrote:
> >>>
> >>> > Hiya all!I wish I could find out who is potentially interested in
> >>> creating
> >>> > the WAVE for a commercial service/productwith my seed startup!Cheers!
> >>> > Adam
> >>> >
> >>> > 20:23 poniedziałek, 2016-3-14, Zachary Yaro  >>> > > napisał(a):
> >>> >
> >>> >
> >>> >  I am inclined to agree with Yuri—if the alternative implementation
> can
> >>> be
> >>> > developed in parallel around the same protocol, that would seem to be
> >>> the
> >>> > best scenario, but the existing codebase should be kept because it is
> >>> > (AFAIK) the most functional implementation of the protocol.
> >>> >
> >>> > Zachary Yaro
> >>> > On Mar 14, 2016 15:05, "Yuri Z" >
> >>> wrote:
> >>> >
> >>> > > I think that more "wavy" projects are nice, but IMO it doesn't
> mean we
> >>> > > should abandon Apache Wave as it is now. I agree there are a lot of
> >>> > issues
> >>> > > with current code, but I think there's still value as people can
> see
> >>> what
> >>> > > Wave can potentially be.
> >>> > >
> >>> > > On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes <
> wisebald...@apache.org
> >>> > >
> >>> > > wrote:
> >>> > >
> >>> > > > The link for those who wish to join, Ill also add this link onto
> the
> >>> > new
> >>> > > > website.
> >>> > > >
> >>> > > > https://www.hipchat.com/gsModF8CY
> >>> > > >
> >>> > > > On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
> >>> > > > michael.macfad...@gmail.com >
> >>> > > > wrote:
> >>> > > >
> >>> > > > > Yeah. Chatting is fine and beneficial. We just need to make
> sure
> >>> we
> >>> > > > > capture key decisions and rationale back in the list for all to
> >>> see.
> >>> > > > >
> >>> > > > > ~Michael
> >>> > > > >
> >>> > > > > > On Mar 12, 2016, at 6:07 PM, Evan Hughes <
> >>> wisebald...@apache.org
> >>> > >
> >>> > > > wrote:
> >>> > > > > >
> >>> > > > > > It does not so as Ive seen other projects state this motto
> "If
> >>> its
> >>> > > not
> >>> > > > on
> >>> > > > > > the mailing list it didnt happen at all", but allows for non
> >>> formal
> >>> > > > talk
> >>> > > > > > and back and forth discussion realtime. The Monthly reports
> >>> that we
> >>> > > > > talked
> >>> > > > > > about back when we did the hangout session should probably be
> >>> > picked
> >>> > > up
> >>> > > > > > again, ill add it to the monthly todo's.
> >>> > > > > >
> >>> > > > > > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
> >>> > > > > michael.macfad...@gmail.com >
> >>> > > > > > wrote:
> >>> > > > > >
> >>> > > > > >> One follow up question though. Does hip hat store
> conversations
> >>> > in a
> >>> > > > > >>

Re: A Wavy Future

2016-03-15 Thread Thomas Wrobel

As a side, I noticed Michael MacFadden mentioned building a rich text
editor in the browser, this much at least have been done in GWT
libraries;
http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/ui/RichTextArea.html

Its fairly basic, but then, I would assume to start with at least any
new wave client should stay fairly basic?
--
http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.


On 15 March 2016 at 15:48, Yuri Z  wrote:
> Yeah, we need to re-use the existing editor. Patches would be great!
>
> On Tue, Mar 15, 2016 at 4:46 PM Pablo Ojanguren  wrote:
>
>> Hi,
>>
>> I agree with the dependency hell issue and the suggestion for throwing
>> away the GWT client. This would require a new client-server API as
>> suggested, however I think a Rest API won't be enough, because real editing
>> needs websocket.
>>
>> I also agree with Michael, developing a new editor is a massive task, so
>> we should use an existing one and plug it in the new API.
>>
>> To write again the server in other language would be great, but I think it
>> requires a huge effort.
>>
>> I will be happy to help in decoupling the server-client, I can provide the
>> experience from my fork. And I plan to send some patches to Wave soon.
>>
>>
>> These are some slides about my fork (swellrt) it could give you some ideas:
>>
>> https://docs.google.com/presentation/d/1WFDS_m7eyNjBjcdPs0zH496Y9bMSl0_JnSEYGjxNFn0/edit?usp=sharing
>>
>> https://docs.google.com/presentation/d/18hMYyECo5EmQsrAb8DT6SkO7LksWVJnhdZmqeCsar4c/edit?usp=sharing
>>
>> btw, I would like to start a business providing these SwellRT services.
>>
>>
>>
>> 2016-03-14 23:27 GMT+01:00 Joseph Gentle :
>>
>>> I've been playing with the idea of starting a company around a rewrite of
>>> wave for years.
>>>
>>> -J
>>>
>>> On Tuesday, 15 March 2016, Adam Bielski 
>>> wrote:
>>>
>>> > Hiya all!I wish I could find out who is potentially interested in
>>> creating
>>> > the WAVE for a commercial service/productwith my seed startup!Cheers!
>>> > Adam
>>> >
>>> > 20:23 poniedziałek, 2016-3-14, Zachary Yaro >> > > napisał(a):
>>> >
>>> >
>>> >  I am inclined to agree with Yuri—if the alternative implementation can
>>> be
>>> > developed in parallel around the same protocol, that would seem to be
>>> the
>>> > best scenario, but the existing codebase should be kept because it is
>>> > (AFAIK) the most functional implementation of the protocol.
>>> >
>>> > Zachary Yaro
>>> > On Mar 14, 2016 15:05, "Yuri Z" >
>>> wrote:
>>> >
>>> > > I think that more "wavy" projects are nice, but IMO it doesn't mean we
>>> > > should abandon Apache Wave as it is now. I agree there are a lot of
>>> > issues
>>> > > with current code, but I think there's still value as people can see
>>> what
>>> > > Wave can potentially be.
>>> > >
>>> > > On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes >> > >
>>> > > wrote:
>>> > >
>>> > > > The link for those who wish to join, Ill also add this link onto the
>>> > new
>>> > > > website.
>>> > > >
>>> > > > https://www.hipchat.com/gsModF8CY
>>> > > >
>>> > > > On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
>>> > > > michael.macfad...@gmail.com >
>>> > > > wrote:
>>> > > >
>>> > > > > Yeah. Chatting is fine and beneficial. We just need to make sure
>>> we
>>> > > > > capture key decisions and rationale back in the list for all to
>>> see.
>>> > > > >
>>> > > > > ~Michael
>>> > > > >
>>> > > > > > On Mar 12, 2016, at 6:07 PM, Evan Hughes <
>>> wisebald...@apache.org
>>> > >
>>> > > > wrote:
>>> > > > > >
>>> > > > > > It does not so as Ive seen other projects state this motto "If
>>> its
>>> > > not
>>> > > > on
>>> > > > > > the mailing list it didnt happen at all", but allows for non
>>> formal
>>> > > > talk
>>> > > > > > and back and forth discussion realtime. The Monthly reports
>>> that we
>>> > > > > talked
>>> > > > > > about back when we did the hangout session should probably be
>>> > picked
>>> > > up
>>> > > > > > again, ill add it to the monthly todo's.
>>> > > > > >
>>> > > > > > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
>>> > > > > michael.macfad...@gmail.com >
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > >> One follow up question though. Does hip hat store conversations
>>> > in a
>>> > > > > >> publicly accessible manner?  If not, we need to make sure key
>>> > > > decisions
>>> > > > > >> that come out of chats are captured and discussed on the
>>> mailing
>>> > > list
>>> > > > > for
>>> > > > > >> all to see.
>>> > > > > >>
>>> > > > > >> ~Michael
>>> > > > > >>
>>> > > > > >>> On Mar 12, 2016, at 7:15 AM, Evan Hughes <
>>> wisebald...@apache.org
>>> > >
>>> > > > > wrote:
>>> > > > > >>>
>>> > > > > >>> I would get infra to make us a

Re: A Wavy Future

2016-03-15 Thread Yuri Z

Yeah, we need to re-use the existing editor. Patches would be great!

On Tue, Mar 15, 2016 at 4:46 PM Pablo Ojanguren  wrote:

> Hi,
>
> I agree with the dependency hell issue and the suggestion for throwing
> away the GWT client. This would require a new client-server API as
> suggested, however I think a Rest API won't be enough, because real editing
> needs websocket.
>
> I also agree with Michael, developing a new editor is a massive task, so
> we should use an existing one and plug it in the new API.
>
> To write again the server in other language would be great, but I think it
> requires a huge effort.
>
> I will be happy to help in decoupling the server-client, I can provide the
> experience from my fork. And I plan to send some patches to Wave soon.
>
>
> These are some slides about my fork (swellrt) it could give you some ideas:
>
> https://docs.google.com/presentation/d/1WFDS_m7eyNjBjcdPs0zH496Y9bMSl0_JnSEYGjxNFn0/edit?usp=sharing
>
> https://docs.google.com/presentation/d/18hMYyECo5EmQsrAb8DT6SkO7LksWVJnhdZmqeCsar4c/edit?usp=sharing
>
> btw, I would like to start a business providing these SwellRT services.
>
>
>
> 2016-03-14 23:27 GMT+01:00 Joseph Gentle :
>
>> I've been playing with the idea of starting a company around a rewrite of
>> wave for years.
>>
>> -J
>>
>> On Tuesday, 15 March 2016, Adam Bielski 
>> wrote:
>>
>> > Hiya all!I wish I could find out who is potentially interested in
>> creating
>> > the WAVE for a commercial service/productwith my seed startup!Cheers!
>> > Adam
>> >
>> > 20:23 poniedziałek, 2016-3-14, Zachary Yaro > > > napisał(a):
>> >
>> >
>> >  I am inclined to agree with Yuri—if the alternative implementation can
>> be
>> > developed in parallel around the same protocol, that would seem to be
>> the
>> > best scenario, but the existing codebase should be kept because it is
>> > (AFAIK) the most functional implementation of the protocol.
>> >
>> > Zachary Yaro
>> > On Mar 14, 2016 15:05, "Yuri Z" >
>> wrote:
>> >
>> > > I think that more "wavy" projects are nice, but IMO it doesn't mean we
>> > > should abandon Apache Wave as it is now. I agree there are a lot of
>> > issues
>> > > with current code, but I think there's still value as people can see
>> what
>> > > Wave can potentially be.
>> > >
>> > > On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes > > >
>> > > wrote:
>> > >
>> > > > The link for those who wish to join, Ill also add this link onto the
>> > new
>> > > > website.
>> > > >
>> > > > https://www.hipchat.com/gsModF8CY
>> > > >
>> > > > On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
>> > > > michael.macfad...@gmail.com >
>> > > > wrote:
>> > > >
>> > > > > Yeah. Chatting is fine and beneficial. We just need to make sure
>> we
>> > > > > capture key decisions and rationale back in the list for all to
>> see.
>> > > > >
>> > > > > ~Michael
>> > > > >
>> > > > > > On Mar 12, 2016, at 6:07 PM, Evan Hughes <
>> wisebald...@apache.org
>> > >
>> > > > wrote:
>> > > > > >
>> > > > > > It does not so as Ive seen other projects state this motto "If
>> its
>> > > not
>> > > > on
>> > > > > > the mailing list it didnt happen at all", but allows for non
>> formal
>> > > > talk
>> > > > > > and back and forth discussion realtime. The Monthly reports
>> that we
>> > > > > talked
>> > > > > > about back when we did the hangout session should probably be
>> > picked
>> > > up
>> > > > > > again, ill add it to the monthly todo's.
>> > > > > >
>> > > > > > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
>> > > > > michael.macfad...@gmail.com >
>> > > > > > wrote:
>> > > > > >
>> > > > > >> One follow up question though. Does hip hat store conversations
>> > in a
>> > > > > >> publicly accessible manner?  If not, we need to make sure key
>> > > > decisions
>> > > > > >> that come out of chats are captured and discussed on the
>> mailing
>> > > list
>> > > > > for
>> > > > > >> all to see.
>> > > > > >>
>> > > > > >> ~Michael
>> > > > > >>
>> > > > > >>> On Mar 12, 2016, at 7:15 AM, Evan Hughes <
>> wisebald...@apache.org
>> > >
>> > > > > wrote:
>> > > > > >>>
>> > > > > >>> I would get infra to make us a hipchat channel so we have some
>> > > place
>> > > > to
>> > > > > >>> talk casually web interface / irc, but seesm the jira's down.
>> > > Looking
>> > > > > to
>> > > > > >>> getting this rolling in some way or another by mid week.
>> > > > > >>>
>> > > > > >>> ~ Evan
>> > > > > >>>
>> > > > >  On Fri, 11 Mar 2016 at 19:48 Evan Hughes <
>> > wisebald...@apache.org >
>> > > > > >> wrote:
>> > > > > 
>> > > > >  The client-server protocol would define a protobuf and json
>> rest
>> > > > > >> services
>> > > > >  so any language that support protocol buffers would be able
>> to
>> > > make
>> > > > a
>> > > > >

Re: A Wavy Future

2016-03-15 Thread Pablo Ojanguren

Hi,

I agree with the dependency hell issue and the suggestion for throwing away
the GWT client. This would require a new client-server API as suggested,
however I think a Rest API won't be enough, because real editing needs
websocket.

I also agree with Michael, developing a new editor is a massive task, so we
should use an existing one and plug it in the new API.

To write again the server in other language would be great, but I think it
requires a huge effort.

I will be happy to help in decoupling the server-client, I can provide the
experience from my fork. And I plan to send some patches to Wave soon.


These are some slides about my fork (swellrt) it could give you some ideas:
https://docs.google.com/presentation/d/1WFDS_m7eyNjBjcdPs0zH496Y9bMSl0_JnSEYGjxNFn0/edit?usp=sharing
https://docs.google.com/presentation/d/18hMYyECo5EmQsrAb8DT6SkO7LksWVJnhdZmqeCsar4c/edit?usp=sharing

btw, I would like to start a business providing these SwellRT services.



2016-03-14 23:27 GMT+01:00 Joseph Gentle :

> I've been playing with the idea of starting a company around a rewrite of
> wave for years.
>
> -J
>
> On Tuesday, 15 March 2016, Adam Bielski 
> wrote:
>
> > Hiya all!I wish I could find out who is potentially interested in
> creating
> > the WAVE for a commercial service/productwith my seed startup!Cheers!
> > Adam
> >
> > 20:23 poniedziałek, 2016-3-14, Zachary Yaro  > > napisał(a):
> >
> >
> >  I am inclined to agree with Yuri—if the alternative implementation can
> be
> > developed in parallel around the same protocol, that would seem to be the
> > best scenario, but the existing codebase should be kept because it is
> > (AFAIK) the most functional implementation of the protocol.
> >
> > Zachary Yaro
> > On Mar 14, 2016 15:05, "Yuri Z" >
> wrote:
> >
> > > I think that more "wavy" projects are nice, but IMO it doesn't mean we
> > > should abandon Apache Wave as it is now. I agree there are a lot of
> > issues
> > > with current code, but I think there's still value as people can see
> what
> > > Wave can potentially be.
> > >
> > > On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes  > >
> > > wrote:
> > >
> > > > The link for those who wish to join, Ill also add this link onto the
> > new
> > > > website.
> > > >
> > > > https://www.hipchat.com/gsModF8CY
> > > >
> > > > On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
> > > > michael.macfad...@gmail.com >
> > > > wrote:
> > > >
> > > > > Yeah. Chatting is fine and beneficial. We just need to make sure we
> > > > > capture key decisions and rationale back in the list for all to
> see.
> > > > >
> > > > > ~Michael
> > > > >
> > > > > > On Mar 12, 2016, at 6:07 PM, Evan Hughes  > >
> > > > wrote:
> > > > > >
> > > > > > It does not so as Ive seen other projects state this motto "If
> its
> > > not
> > > > on
> > > > > > the mailing list it didnt happen at all", but allows for non
> formal
> > > > talk
> > > > > > and back and forth discussion realtime. The Monthly reports that
> we
> > > > > talked
> > > > > > about back when we did the hangout session should probably be
> > picked
> > > up
> > > > > > again, ill add it to the monthly todo's.
> > > > > >
> > > > > > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
> > > > > michael.macfad...@gmail.com >
> > > > > > wrote:
> > > > > >
> > > > > >> One follow up question though. Does hip hat store conversations
> > in a
> > > > > >> publicly accessible manner?  If not, we need to make sure key
> > > > decisions
> > > > > >> that come out of chats are captured and discussed on the mailing
> > > list
> > > > > for
> > > > > >> all to see.
> > > > > >>
> > > > > >> ~Michael
> > > > > >>
> > > > > >>> On Mar 12, 2016, at 7:15 AM, Evan Hughes <
> wisebald...@apache.org
> > >
> > > > > wrote:
> > > > > >>>
> > > > > >>> I would get infra to make us a hipchat channel so we have some
> > > place
> > > > to
> > > > > >>> talk casually web interface / irc, but seesm the jira's down.
> > > Looking
> > > > > to
> > > > > >>> getting this rolling in some way or another by mid week.
> > > > > >>>
> > > > > >>> ~ Evan
> > > > > >>>
> > > > >  On Fri, 11 Mar 2016 at 19:48 Evan Hughes <
> > wisebald...@apache.org >
> > > > > >> wrote:
> > > > > 
> > > > >  The client-server protocol would define a protobuf and json
> rest
> > > > > >> services
> > > > >  so any language that support protocol buffers would be able to
> > > make
> > > > a
> > > > >  client or fallback to the json rest.
> > > > > 
> > > > > 
> > > > >  On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
> > > > > >> count-apache@flatline.de >
> > > > >  wrote:
> > > > > 
> > > > > > FWIW,
> > > > > >
> > > > > > I also consider the idea pretty good and would

Re: A Wavy Future

2016-03-14 Thread Joseph Gentle

I've been playing with the idea of starting a company around a rewrite of
wave for years.

-J

On Tuesday, 15 March 2016, Adam Bielski  wrote:

> Hiya all!I wish I could find out who is potentially interested in creating
> the WAVE for a commercial service/productwith my seed startup!Cheers!
> Adam
>
> 20:23 poniedziałek, 2016-3-14, Zachary Yaro  > napisał(a):
>
>
>  I am inclined to agree with Yuri—if the alternative implementation can be
> developed in parallel around the same protocol, that would seem to be the
> best scenario, but the existing codebase should be kept because it is
> (AFAIK) the most functional implementation of the protocol.
>
> Zachary Yaro
> On Mar 14, 2016 15:05, "Yuri Z" > wrote:
>
> > I think that more "wavy" projects are nice, but IMO it doesn't mean we
> > should abandon Apache Wave as it is now. I agree there are a lot of
> issues
> > with current code, but I think there's still value as people can see what
> > Wave can potentially be.
> >
> > On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes  >
> > wrote:
> >
> > > The link for those who wish to join, Ill also add this link onto the
> new
> > > website.
> > >
> > > https://www.hipchat.com/gsModF8CY
> > >
> > > On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
> > > michael.macfad...@gmail.com >
> > > wrote:
> > >
> > > > Yeah. Chatting is fine and beneficial. We just need to make sure we
> > > > capture key decisions and rationale back in the list for all to see.
> > > >
> > > > ~Michael
> > > >
> > > > > On Mar 12, 2016, at 6:07 PM, Evan Hughes  >
> > > wrote:
> > > > >
> > > > > It does not so as Ive seen other projects state this motto "If its
> > not
> > > on
> > > > > the mailing list it didnt happen at all", but allows for non formal
> > > talk
> > > > > and back and forth discussion realtime. The Monthly reports that we
> > > > talked
> > > > > about back when we did the hangout session should probably be
> picked
> > up
> > > > > again, ill add it to the monthly todo's.
> > > > >
> > > > > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
> > > > michael.macfad...@gmail.com >
> > > > > wrote:
> > > > >
> > > > >> One follow up question though. Does hip hat store conversations
> in a
> > > > >> publicly accessible manner?  If not, we need to make sure key
> > > decisions
> > > > >> that come out of chats are captured and discussed on the mailing
> > list
> > > > for
> > > > >> all to see.
> > > > >>
> > > > >> ~Michael
> > > > >>
> > > > >>> On Mar 12, 2016, at 7:15 AM, Evan Hughes  >
> > > > wrote:
> > > > >>>
> > > > >>> I would get infra to make us a hipchat channel so we have some
> > place
> > > to
> > > > >>> talk casually web interface / irc, but seesm the jira's down.
> > Looking
> > > > to
> > > > >>> getting this rolling in some way or another by mid week.
> > > > >>>
> > > > >>> ~ Evan
> > > > >>>
> > > >  On Fri, 11 Mar 2016 at 19:48 Evan Hughes <
> wisebald...@apache.org >
> > > > >> wrote:
> > > > 
> > > >  The client-server protocol would define a protobuf and json rest
> > > > >> services
> > > >  so any language that support protocol buffers would be able to
> > make
> > > a
> > > >  client or fallback to the json rest.
> > > > 
> > > > 
> > > >  On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
> > > > >> count-apache@flatline.de >
> > > >  wrote:
> > > > 
> > > > > FWIW,
> > > > >
> > > > > I also consider the idea pretty good and would want stronger
> > > > decoupling
> > > > > of server/client. I'd be interested in a python client
> > > > implementation,
> > > > > mostly for CLI and bot integration.
> > > > >
> > > > > Not sure whether doing a client-side C implementation of the
> > > > > communication protocol would be best here (so wrapper for more
> > > > >> languages
> > > > > can follow), or whether native Python would be better. We need
> > > > >> something
> > > > > for non-Java folks in any case, I think.
> > > > >
> > > > > Cheers,
> > > > >
> > > > >  count
> > > > >
> > > > >> On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
> > > > >> Thankyou all for your feedback and expressions of interests,
> > seems
> > > > >> like
> > > > > we
> > > > >> may be able to develop some teams together to make this a
> faster
> > > > >> reality
> > > > >> than just I. Hopefully we can get some more people to express
> > > > >> interests
> > > > > in
> > > > >> this way forward.
> > > > >
> > > > > --
> > > > > Andreas 'count' Kotes
> > > > > Taming computers for humans since 1990.
> > > > > "Don't ask what the world needs. Ask what makes you come alive,
> > and
> > > > go
> > > > >> do
>

Re: A Wavy Future

2016-03-14 Thread Adam Bielski

Hiya all!I wish I could find out who is potentially interested in creating the 
WAVE for a commercial service/productwith my seed startup!Cheers!
Adam 

20:23 poniedziałek, 2016-3-14, Zachary Yaro  napisał(a):
 

 I am inclined to agree with Yuri—if the alternative implementation can be
developed in parallel around the same protocol, that would seem to be the
best scenario, but the existing codebase should be kept because it is
(AFAIK) the most functional implementation of the protocol.

Zachary Yaro
On Mar 14, 2016 15:05, "Yuri Z"  wrote:

> I think that more "wavy" projects are nice, but IMO it doesn't mean we
> should abandon Apache Wave as it is now. I agree there are a lot of issues
> with current code, but I think there's still value as people can see what
> Wave can potentially be.
>
> On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes 
> wrote:
>
> > The link for those who wish to join, Ill also add this link onto the new
> > website.
> >
> > https://www.hipchat.com/gsModF8CY
> >
> > On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
> > michael.macfad...@gmail.com>
> > wrote:
> >
> > > Yeah. Chatting is fine and beneficial. We just need to make sure we
> > > capture key decisions and rationale back in the list for all to see.
> > >
> > > ~Michael
> > >
> > > > On Mar 12, 2016, at 6:07 PM, Evan Hughes 
> > wrote:
> > > >
> > > > It does not so as Ive seen other projects state this motto "If its
> not
> > on
> > > > the mailing list it didnt happen at all", but allows for non formal
> > talk
> > > > and back and forth discussion realtime. The Monthly reports that we
> > > talked
> > > > about back when we did the hangout session should probably be picked
> up
> > > > again, ill add it to the monthly todo's.
> > > >
> > > > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
> > > michael.macfad...@gmail.com>
> > > > wrote:
> > > >
> > > >> One follow up question though. Does hip hat store conversations in a
> > > >> publicly accessible manner?  If not, we need to make sure key
> > decisions
> > > >> that come out of chats are captured and discussed on the mailing
> list
> > > for
> > > >> all to see.
> > > >>
> > > >> ~Michael
> > > >>
> > > >>> On Mar 12, 2016, at 7:15 AM, Evan Hughes 
> > > wrote:
> > > >>>
> > > >>> I would get infra to make us a hipchat channel so we have some
> place
> > to
> > > >>> talk casually web interface / irc, but seesm the jira's down.
> Looking
> > > to
> > > >>> getting this rolling in some way or another by mid week.
> > > >>>
> > > >>> ~ Evan
> > > >>>
> > >  On Fri, 11 Mar 2016 at 19:48 Evan Hughes 
> > > >> wrote:
> > > 
> > >  The client-server protocol would define a protobuf and json rest
> > > >> services
> > >  so any language that support protocol buffers would be able to
> make
> > a
> > >  client or fallback to the json rest.
> > > 
> > > 
> > >  On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
> > > >> count-apache@flatline.de>
> > >  wrote:
> > > 
> > > > FWIW,
> > > >
> > > > I also consider the idea pretty good and would want stronger
> > > decoupling
> > > > of server/client. I'd be interested in a python client
> > > implementation,
> > > > mostly for CLI and bot integration.
> > > >
> > > > Not sure whether doing a client-side C implementation of the
> > > > communication protocol would be best here (so wrapper for more
> > > >> languages
> > > > can follow), or whether native Python would be better. We need
> > > >> something
> > > > for non-Java folks in any case, I think.
> > > >
> > > > Cheers,
> > > >
> > > >  count
> > > >
> > > >> On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
> > > >> Thankyou all for your feedback and expressions of interests,
> seems
> > > >> like
> > > > we
> > > >> may be able to develop some teams together to make this a faster
> > > >> reality
> > > >> than just I. Hopefully we can get some more people to express
> > > >> interests
> > > > in
> > > >> this way forward.
> > > >
> > > > --
> > > > Andreas 'count' Kotes
> > > > Taming computers for humans since 1990.
> > > > "Don't ask what the world needs. Ask what makes you come alive,
> and
> > > go
> > > >> do
> > > > it.
> > > > Because what the world needs is people who have come alive." --
> > > Howard
> > > > Thurman
> > > >>
> > >
> >
>

Re: A Wavy Future

2016-03-14 Thread Zachary Yaro

I am inclined to agree with Yuri—if the alternative implementation can be
developed in parallel around the same protocol, that would seem to be the
best scenario, but the existing codebase should be kept because it is
(AFAIK) the most functional implementation of the protocol.

Zachary Yaro
On Mar 14, 2016 15:05, "Yuri Z"  wrote:

> I think that more "wavy" projects are nice, but IMO it doesn't mean we
> should abandon Apache Wave as it is now. I agree there are a lot of issues
> with current code, but I think there's still value as people can see what
> Wave can potentially be.
>
> On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes 
> wrote:
>
> > The link for those who wish to join, Ill also add this link onto the new
> > website.
> >
> > https://www.hipchat.com/gsModF8CY
> >
> > On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
> > michael.macfad...@gmail.com>
> > wrote:
> >
> > > Yeah. Chatting is fine and beneficial. We just need to make sure we
> > > capture key decisions and rationale back in the list for all to see.
> > >
> > > ~Michael
> > >
> > > > On Mar 12, 2016, at 6:07 PM, Evan Hughes 
> > wrote:
> > > >
> > > > It does not so as Ive seen other projects state this motto "If its
> not
> > on
> > > > the mailing list it didnt happen at all", but allows for non formal
> > talk
> > > > and back and forth discussion realtime. The Monthly reports that we
> > > talked
> > > > about back when we did the hangout session should probably be picked
> up
> > > > again, ill add it to the monthly todo's.
> > > >
> > > > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
> > > michael.macfad...@gmail.com>
> > > > wrote:
> > > >
> > > >> One follow up question though. Does hip hat store conversations in a
> > > >> publicly accessible manner?  If not, we need to make sure key
> > decisions
> > > >> that come out of chats are captured and discussed on the mailing
> list
> > > for
> > > >> all to see.
> > > >>
> > > >> ~Michael
> > > >>
> > > >>> On Mar 12, 2016, at 7:15 AM, Evan Hughes 
> > > wrote:
> > > >>>
> > > >>> I would get infra to make us a hipchat channel so we have some
> place
> > to
> > > >>> talk casually web interface / irc, but seesm the jira's down.
> Looking
> > > to
> > > >>> getting this rolling in some way or another by mid week.
> > > >>>
> > > >>> ~ Evan
> > > >>>
> > >  On Fri, 11 Mar 2016 at 19:48 Evan Hughes 
> > > >> wrote:
> > > 
> > >  The client-server protocol would define a protobuf and json rest
> > > >> services
> > >  so any language that support protocol buffers would be able to
> make
> > a
> > >  client or fallback to the json rest.
> > > 
> > > 
> > >  On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
> > > >> count-apache@flatline.de>
> > >  wrote:
> > > 
> > > > FWIW,
> > > >
> > > > I also consider the idea pretty good and would want stronger
> > > decoupling
> > > > of server/client. I'd be interested in a python client
> > > implementation,
> > > > mostly for CLI and bot integration.
> > > >
> > > > Not sure whether doing a client-side C implementation of the
> > > > communication protocol would be best here (so wrapper for more
> > > >> languages
> > > > can follow), or whether native Python would be better. We need
> > > >> something
> > > > for non-Java folks in any case, I think.
> > > >
> > > > Cheers,
> > > >
> > > >  count
> > > >
> > > >> On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
> > > >> Thankyou all for your feedback and expressions of interests,
> seems
> > > >> like
> > > > we
> > > >> may be able to develop some teams together to make this a faster
> > > >> reality
> > > >> than just I. Hopefully we can get some more people to express
> > > >> interests
> > > > in
> > > >> this way forward.
> > > >
> > > > --
> > > > Andreas 'count' Kotes
> > > > Taming computers for humans since 1990.
> > > > "Don't ask what the world needs. Ask what makes you come alive,
> and
> > > go
> > > >> do
> > > > it.
> > > > Because what the world needs is people who have come alive." --
> > > Howard
> > > > Thurman
> > > >>
> > >
> >
>

Re: A Wavy Future

2016-03-14 Thread Yuri Z

I think that more "wavy" projects are nice, but IMO it doesn't mean we
should abandon Apache Wave as it is now. I agree there are a lot of issues
with current code, but I think there's still value as people can see what
Wave can potentially be.

On Sun, Mar 13, 2016 at 8:46 AM Evan Hughes  wrote:

> The link for those who wish to join, Ill also add this link onto the new
> website.
>
> https://www.hipchat.com/gsModF8CY
>
> On Sun, 13 Mar 2016 at 12:12 Michael MacFadden <
> michael.macfad...@gmail.com>
> wrote:
>
> > Yeah. Chatting is fine and beneficial. We just need to make sure we
> > capture key decisions and rationale back in the list for all to see.
> >
> > ~Michael
> >
> > > On Mar 12, 2016, at 6:07 PM, Evan Hughes 
> wrote:
> > >
> > > It does not so as Ive seen other projects state this motto "If its not
> on
> > > the mailing list it didnt happen at all", but allows for non formal
> talk
> > > and back and forth discussion realtime. The Monthly reports that we
> > talked
> > > about back when we did the hangout session should probably be picked up
> > > again, ill add it to the monthly todo's.
> > >
> > > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
> > michael.macfad...@gmail.com>
> > > wrote:
> > >
> > >> One follow up question though. Does hip hat store conversations in a
> > >> publicly accessible manner?  If not, we need to make sure key
> decisions
> > >> that come out of chats are captured and discussed on the mailing list
> > for
> > >> all to see.
> > >>
> > >> ~Michael
> > >>
> > >>> On Mar 12, 2016, at 7:15 AM, Evan Hughes 
> > wrote:
> > >>>
> > >>> I would get infra to make us a hipchat channel so we have some place
> to
> > >>> talk casually web interface / irc, but seesm the jira's down. Looking
> > to
> > >>> getting this rolling in some way or another by mid week.
> > >>>
> > >>> ~ Evan
> > >>>
> >  On Fri, 11 Mar 2016 at 19:48 Evan Hughes 
> > >> wrote:
> > 
> >  The client-server protocol would define a protobuf and json rest
> > >> services
> >  so any language that support protocol buffers would be able to make
> a
> >  client or fallback to the json rest.
> > 
> > 
> >  On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
> > >> count-apache@flatline.de>
> >  wrote:
> > 
> > > FWIW,
> > >
> > > I also consider the idea pretty good and would want stronger
> > decoupling
> > > of server/client. I'd be interested in a python client
> > implementation,
> > > mostly for CLI and bot integration.
> > >
> > > Not sure whether doing a client-side C implementation of the
> > > communication protocol would be best here (so wrapper for more
> > >> languages
> > > can follow), or whether native Python would be better. We need
> > >> something
> > > for non-Java folks in any case, I think.
> > >
> > > Cheers,
> > >
> > >  count
> > >
> > >> On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
> > >> Thankyou all for your feedback and expressions of interests, seems
> > >> like
> > > we
> > >> may be able to develop some teams together to make this a faster
> > >> reality
> > >> than just I. Hopefully we can get some more people to express
> > >> interests
> > > in
> > >> this way forward.
> > >
> > > --
> > > Andreas 'count' Kotes
> > > Taming computers for humans since 1990.
> > > "Don't ask what the world needs. Ask what makes you come alive, and
> > go
> > >> do
> > > it.
> > > Because what the world needs is people who have come alive." --
> > Howard
> > > Thurman
> > >>
> >
>

Re: A Wavy Future

2016-03-12 Thread Evan Hughes

The link for those who wish to join, Ill also add this link onto the new
website.

https://www.hipchat.com/gsModF8CY

On Sun, 13 Mar 2016 at 12:12 Michael MacFadden 
wrote:

> Yeah. Chatting is fine and beneficial. We just need to make sure we
> capture key decisions and rationale back in the list for all to see.
>
> ~Michael
>
> > On Mar 12, 2016, at 6:07 PM, Evan Hughes  wrote:
> >
> > It does not so as Ive seen other projects state this motto "If its not on
> > the mailing list it didnt happen at all", but allows for non formal talk
> > and back and forth discussion realtime. The Monthly reports that we
> talked
> > about back when we did the hangout session should probably be picked up
> > again, ill add it to the monthly todo's.
> >
> > On Sun, 13 Mar 2016 at 11:58 Michael MacFadden <
> michael.macfad...@gmail.com>
> > wrote:
> >
> >> One follow up question though. Does hip hat store conversations in a
> >> publicly accessible manner?  If not, we need to make sure key decisions
> >> that come out of chats are captured and discussed on the mailing list
> for
> >> all to see.
> >>
> >> ~Michael
> >>
> >>> On Mar 12, 2016, at 7:15 AM, Evan Hughes 
> wrote:
> >>>
> >>> I would get infra to make us a hipchat channel so we have some place to
> >>> talk casually web interface / irc, but seesm the jira's down. Looking
> to
> >>> getting this rolling in some way or another by mid week.
> >>>
> >>> ~ Evan
> >>>
>  On Fri, 11 Mar 2016 at 19:48 Evan Hughes 
> >> wrote:
> 
>  The client-server protocol would define a protobuf and json rest
> >> services
>  so any language that support protocol buffers would be able to make a
>  client or fallback to the json rest.
> 
> 
>  On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
> >> count-apache@flatline.de>
>  wrote:
> 
> > FWIW,
> >
> > I also consider the idea pretty good and would want stronger
> decoupling
> > of server/client. I'd be interested in a python client
> implementation,
> > mostly for CLI and bot integration.
> >
> > Not sure whether doing a client-side C implementation of the
> > communication protocol would be best here (so wrapper for more
> >> languages
> > can follow), or whether native Python would be better. We need
> >> something
> > for non-Java folks in any case, I think.
> >
> > Cheers,
> >
> >  count
> >
> >> On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
> >> Thankyou all for your feedback and expressions of interests, seems
> >> like
> > we
> >> may be able to develop some teams together to make this a faster
> >> reality
> >> than just I. Hopefully we can get some more people to express
> >> interests
> > in
> >> this way forward.
> >
> > --
> > Andreas 'count' Kotes
> > Taming computers for humans since 1990.
> > "Don't ask what the world needs. Ask what makes you come alive, and
> go
> >> do
> > it.
> > Because what the world needs is people who have come alive." --
> Howard
> > Thurman
> >>
>

Re: A Wavy Future

2016-03-12 Thread Michael MacFadden

Yeah. Chatting is fine and beneficial. We just need to make sure we capture key 
decisions and rationale back in the list for all to see. 

~Michael

> On Mar 12, 2016, at 6:07 PM, Evan Hughes  wrote:
> 
> It does not so as Ive seen other projects state this motto "If its not on
> the mailing list it didnt happen at all", but allows for non formal talk
> and back and forth discussion realtime. The Monthly reports that we talked
> about back when we did the hangout session should probably be picked up
> again, ill add it to the monthly todo's.
> 
> On Sun, 13 Mar 2016 at 11:58 Michael MacFadden 
> wrote:
> 
>> One follow up question though. Does hip hat store conversations in a
>> publicly accessible manner?  If not, we need to make sure key decisions
>> that come out of chats are captured and discussed on the mailing list for
>> all to see.
>> 
>> ~Michael
>> 
>>> On Mar 12, 2016, at 7:15 AM, Evan Hughes  wrote:
>>> 
>>> I would get infra to make us a hipchat channel so we have some place to
>>> talk casually web interface / irc, but seesm the jira's down. Looking to
>>> getting this rolling in some way or another by mid week.
>>> 
>>> ~ Evan
>>> 
 On Fri, 11 Mar 2016 at 19:48 Evan Hughes 
>> wrote:
 
 The client-server protocol would define a protobuf and json rest
>> services
 so any language that support protocol buffers would be able to make a
 client or fallback to the json rest.
 
 
 On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
>> count-apache@flatline.de>
 wrote:
 
> FWIW,
> 
> I also consider the idea pretty good and would want stronger decoupling
> of server/client. I'd be interested in a python client implementation,
> mostly for CLI and bot integration.
> 
> Not sure whether doing a client-side C implementation of the
> communication protocol would be best here (so wrapper for more
>> languages
> can follow), or whether native Python would be better. We need
>> something
> for non-Java folks in any case, I think.
> 
> Cheers,
> 
>  count
> 
>> On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
>> Thankyou all for your feedback and expressions of interests, seems
>> like
> we
>> may be able to develop some teams together to make this a faster
>> reality
>> than just I. Hopefully we can get some more people to express
>> interests
> in
>> this way forward.
> 
> --
> Andreas 'count' Kotes
> Taming computers for humans since 1990.
> "Don't ask what the world needs. Ask what makes you come alive, and go
>> do
> it.
> Because what the world needs is people who have come alive." -- Howard
> Thurman
>>

Re: A Wavy Future

2016-03-12 Thread Andreas Kotes

Gee, if only we had a system where interactive edits and conversations
could be stored with something like a timeline in form of something like
a wiki ... ;)

   count

On Sat, Mar 12, 2016 at 05:58:45PM -0800, Michael MacFadden wrote:
> One follow up question though. Does hip hat store conversations in a
> publicly accessible manner?  If not, we need to make sure key
> decisions that come out of chats are captured and discussed on the
> mailing list for all to see. 
> 
> > On Mar 12, 2016, at 7:15 AM, Evan Hughes  wrote:
> > I would get infra to make us a hipchat channel so we have some place
> > to talk casually web interface / irc, but seesm the jira's down.
> > Looking to getting this rolling in some way or another by mid week.

-- 
Andreas 'count' Kotes
Taming computers for humans since 1990.
"Don't ask what the world needs. Ask what makes you come alive, and go do it.
Because what the world needs is people who have come alive." -- Howard Thurman

Re: A Wavy Future

2016-03-12 Thread Evan Hughes

It does not so as Ive seen other projects state this motto "If its not on
the mailing list it didnt happen at all", but allows for non formal talk
and back and forth discussion realtime. The Monthly reports that we talked
about back when we did the hangout session should probably be picked up
again, ill add it to the monthly todo's.

On Sun, 13 Mar 2016 at 11:58 Michael MacFadden 
wrote:

> One follow up question though. Does hip hat store conversations in a
> publicly accessible manner?  If not, we need to make sure key decisions
> that come out of chats are captured and discussed on the mailing list for
> all to see.
>
> ~Michael
>
> > On Mar 12, 2016, at 7:15 AM, Evan Hughes  wrote:
> >
> > I would get infra to make us a hipchat channel so we have some place to
> > talk casually web interface / irc, but seesm the jira's down. Looking to
> > getting this rolling in some way or another by mid week.
> >
> > ~ Evan
> >
> >> On Fri, 11 Mar 2016 at 19:48 Evan Hughes 
> wrote:
> >>
> >> The client-server protocol would define a protobuf and json rest
> services
> >> so any language that support protocol buffers would be able to make a
> >> client or fallback to the json rest.
> >>
> >>
> >> On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
> count-apache@flatline.de>
> >> wrote:
> >>
> >>> FWIW,
> >>>
> >>> I also consider the idea pretty good and would want stronger decoupling
> >>> of server/client. I'd be interested in a python client implementation,
> >>> mostly for CLI and bot integration.
> >>>
> >>> Not sure whether doing a client-side C implementation of the
> >>> communication protocol would be best here (so wrapper for more
> languages
> >>> can follow), or whether native Python would be better. We need
> something
> >>> for non-Java folks in any case, I think.
> >>>
> >>> Cheers,
> >>>
> >>>   count
> >>>
>  On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
>  Thankyou all for your feedback and expressions of interests, seems
> like
> >>> we
>  may be able to develop some teams together to make this a faster
> reality
>  than just I. Hopefully we can get some more people to express
> interests
> >>> in
>  this way forward.
> >>>
> >>> --
> >>> Andreas 'count' Kotes
> >>> Taming computers for humans since 1990.
> >>> "Don't ask what the world needs. Ask what makes you come alive, and go
> do
> >>> it.
> >>> Because what the world needs is people who have come alive." -- Howard
> >>> Thurman
> >>
>

Re: A Wavy Future

2016-03-12 Thread Michael MacFadden

One follow up question though. Does hip hat store conversations in a publicly 
accessible manner?  If not, we need to make sure key decisions that come out of 
chats are captured and discussed on the mailing list for all to see. 

~Michael

> On Mar 12, 2016, at 7:15 AM, Evan Hughes  wrote:
> 
> I would get infra to make us a hipchat channel so we have some place to
> talk casually web interface / irc, but seesm the jira's down. Looking to
> getting this rolling in some way or another by mid week.
> 
> ~ Evan
> 
>> On Fri, 11 Mar 2016 at 19:48 Evan Hughes  wrote:
>> 
>> The client-server protocol would define a protobuf and json rest services
>> so any language that support protocol buffers would be able to make a
>> client or fallback to the json rest.
>> 
>> 
>> On Fri, 11 Mar 2016 at 19:24 Andreas Kotes 
>> wrote:
>> 
>>> FWIW,
>>> 
>>> I also consider the idea pretty good and would want stronger decoupling
>>> of server/client. I'd be interested in a python client implementation,
>>> mostly for CLI and bot integration.
>>> 
>>> Not sure whether doing a client-side C implementation of the
>>> communication protocol would be best here (so wrapper for more languages
>>> can follow), or whether native Python would be better. We need something
>>> for non-Java folks in any case, I think.
>>> 
>>> Cheers,
>>> 
>>>   count
>>> 
 On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
 Thankyou all for your feedback and expressions of interests, seems like
>>> we
 may be able to develop some teams together to make this a faster reality
 than just I. Hopefully we can get some more people to express interests
>>> in
 this way forward.
>>> 
>>> --
>>> Andreas 'count' Kotes
>>> Taming computers for humans since 1990.
>>> "Don't ask what the world needs. Ask what makes you come alive, and go do
>>> it.
>>> Because what the world needs is people who have come alive." -- Howard
>>> Thurman
>>

Re: A Wavy Future

2016-03-12 Thread Michael MacFadden

Sounds great. 

~Michael

> On Mar 12, 2016, at 7:15 AM, Evan Hughes  wrote:
> 
> I would get infra to make us a hipchat channel so we have some place to
> talk casually web interface / irc, but seesm the jira's down. Looking to
> getting this rolling in some way or another by mid week.
> 
> ~ Evan
> 
>> On Fri, 11 Mar 2016 at 19:48 Evan Hughes  wrote:
>> 
>> The client-server protocol would define a protobuf and json rest services
>> so any language that support protocol buffers would be able to make a
>> client or fallback to the json rest.
>> 
>> 
>> On Fri, 11 Mar 2016 at 19:24 Andreas Kotes 
>> wrote:
>> 
>>> FWIW,
>>> 
>>> I also consider the idea pretty good and would want stronger decoupling
>>> of server/client. I'd be interested in a python client implementation,
>>> mostly for CLI and bot integration.
>>> 
>>> Not sure whether doing a client-side C implementation of the
>>> communication protocol would be best here (so wrapper for more languages
>>> can follow), or whether native Python would be better. We need something
>>> for non-Java folks in any case, I think.
>>> 
>>> Cheers,
>>> 
>>>   count
>>> 
 On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
 Thankyou all for your feedback and expressions of interests, seems like
>>> we
 may be able to develop some teams together to make this a faster reality
 than just I. Hopefully we can get some more people to express interests
>>> in
 this way forward.
>>> 
>>> --
>>> Andreas 'count' Kotes
>>> Taming computers for humans since 1990.
>>> "Don't ask what the world needs. Ask what makes you come alive, and go do
>>> it.
>>> Because what the world needs is people who have come alive." -- Howard
>>> Thurman
>>

Re: A Wavy Future

2016-03-12 Thread Evan Hughes

I would get infra to make us a hipchat channel so we have some place to
talk casually web interface / irc, but seesm the jira's down. Looking to
getting this rolling in some way or another by mid week.

~ Evan

On Fri, 11 Mar 2016 at 19:48 Evan Hughes  wrote:

> The client-server protocol would define a protobuf and json rest services
> so any language that support protocol buffers would be able to make a
> client or fallback to the json rest.
>
>
> On Fri, 11 Mar 2016 at 19:24 Andreas Kotes 
> wrote:
>
>> FWIW,
>>
>> I also consider the idea pretty good and would want stronger decoupling
>> of server/client. I'd be interested in a python client implementation,
>> mostly for CLI and bot integration.
>>
>> Not sure whether doing a client-side C implementation of the
>> communication protocol would be best here (so wrapper for more languages
>> can follow), or whether native Python would be better. We need something
>> for non-Java folks in any case, I think.
>>
>> Cheers,
>>
>>count
>>
>> On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
>> > Thankyou all for your feedback and expressions of interests, seems like
>> we
>> > may be able to develop some teams together to make this a faster reality
>> > than just I. Hopefully we can get some more people to express interests
>> in
>> > this way forward.
>>
>> --
>> Andreas 'count' Kotes
>> Taming computers for humans since 1990.
>> "Don't ask what the world needs. Ask what makes you come alive, and go do
>> it.
>> Because what the world needs is people who have come alive." -- Howard
>> Thurman
>>
>

Re: A Wavy Future

2016-03-11 Thread Evan Hughes

The client-server protocol would define a protobuf and json rest services
so any language that support protocol buffers would be able to make a
client or fallback to the json rest.

On Fri, 11 Mar 2016 at 19:24 Andreas Kotes 
wrote:

> FWIW,
>
> I also consider the idea pretty good and would want stronger decoupling
> of server/client. I'd be interested in a python client implementation,
> mostly for CLI and bot integration.
>
> Not sure whether doing a client-side C implementation of the
> communication protocol would be best here (so wrapper for more languages
> can follow), or whether native Python would be better. We need something
> for non-Java folks in any case, I think.
>
> Cheers,
>
>count
>
> On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
> > Thankyou all for your feedback and expressions of interests, seems like
> we
> > may be able to develop some teams together to make this a faster reality
> > than just I. Hopefully we can get some more people to express interests
> in
> > this way forward.
>
> --
> Andreas 'count' Kotes
> Taming computers for humans since 1990.
> "Don't ask what the world needs. Ask what makes you come alive, and go do
> it.
> Because what the world needs is people who have come alive." -- Howard
> Thurman
>

Re: A Wavy Future

2016-03-11 Thread Andreas Kotes

FWIW,

I also consider the idea pretty good and would want stronger decoupling
of server/client. I'd be interested in a python client implementation,
mostly for CLI and bot integration.

Not sure whether doing a client-side C implementation of the
communication protocol would be best here (so wrapper for more languages
can follow), or whether native Python would be better. We need something
for non-Java folks in any case, I think.

Cheers,

   count

On Fri, Mar 11, 2016 at 10:52:34AM +1000, Evan Hughes wrote:
> Thankyou all for your feedback and expressions of interests, seems like we
> may be able to develop some teams together to make this a faster reality
> than just I. Hopefully we can get some more people to express interests in
> this way forward.

-- 
Andreas 'count' Kotes
Taming computers for humans since 1990.
"Don't ask what the world needs. Ask what makes you come alive, and go do it.
Because what the world needs is people who have come alive." -- Howard Thurman

Re: A Wavy Future

2016-03-10 Thread Evan Hughes

Thankyou all for your feedback and expressions of interests, seems like we
may be able to develop some teams together to make this a faster reality
than just I. Hopefully we can get some more people to express interests in
this way forward.
On 11/03/2016 9:57 AM, "Jonathan Leong"  wrote:

> Hi guys,
>
> This paragraph caught my eye:
>
> Currently with the project patches and issues aren't given enough attention
> > due to the lack of manpower. However actions can be taken to smooth this
> > process as listed below
>
>
> I'm not a developer, but perhaps I can help out in this area? I've done
> some DevOps/Automation work with Chef and Jenkins.
>
> PS. Long time lurker, but big fan of Wave.
>
>
> -Jonathan Leong
>
>
> On Thu, Mar 10, 2016 at 6:39 PM, Michael MacFadden <
> michael.macfad...@gmail.com> wrote:
>
> > Something that got lost in that translation was, if we were going to go
> > down the path you are considering, I would be interested in the OT
> > subsystem and the protocol.  The main reason I have not been contributing
> > much is simply because we aren’t doing much in those areas.
> >
> >
> >
> >
> > On 3/10/16, 6:37 PM, "Michael MacFadden" 
> > wrote:
> >
> > >Looking over the doc is a good start, I think we could codify some
> > additional things or principles that we would want to account for.
> > >
> > >Personally, my expertise lies in the OT system and the client to server
> > messaging.  Both in the implementation and in the “why/how” of what is
> > there now.
> > >
> > >One thing I would say is that the Client’s data model / rendering
> > approach is fairly sophisticated in two regards.  First building any sort
> > of rich text editor in the browser is some what difficult.  I am not sure
> > that undertaking that particular effort, GWT or otherwise is going to be
> > easy.  The rest of the UI could be easily redone quickly, but the editor
> > would take months and months to do from scratch.  I think we would want
> to
> > consider if we should be looking at using an existing editor that is out
> > there.
> > >
> > >The other area where the UI is complex is in the performance aspect of
> > it.  The wave UI is designed to load a ton of “blips”.  The content over
> > time could become very, very long.  There was some measure of thought put
> > into the current system to make rendering and eventing very fast to
> handle
> > large conversations.
> > >
> > >Just a few thoughts.
> > >
> > >~Michael
> > >
> > >
> > >
> > >
> > >On 3/10/16, 4:34 PM, "Thomas Wrobel"  wrote:
> > >
> > >>As always +1 to separation (speaking as a GWT person not having a clue
> > >>how the server works).
> > >>--
> > >>http://lostagain.nl <-- our company site.
> > >>http://fanficmaker.com <-- our, really,really, bad story generator.
> > >>
> > >>
> > >>On 10 March 2016 at 14:32, Evan Hughes  wrote:
> > >>> Hell all,
> > >>>
> > >>> please see the attached document for my own personal vision for the
> > future
> > >>> of wave,
> > >>>
> > >>>
> >
> https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit?usp=sharing
> > >>>
> > >>>
> > >>> Happy to receive any thoughts on any of the changes.
> > >>>
> > >>> Sincerely,
> > >>> Evan Hughes
> > >
> >
> >
>

Re: A Wavy Future

2016-03-10 Thread Jonathan Leong

Hi guys,

This paragraph caught my eye:

Currently with the project patches and issues aren't given enough attention
> due to the lack of manpower. However actions can be taken to smooth this
> process as listed below


I'm not a developer, but perhaps I can help out in this area? I've done
some DevOps/Automation work with Chef and Jenkins.

PS. Long time lurker, but big fan of Wave.


-Jonathan Leong


On Thu, Mar 10, 2016 at 6:39 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:

> Something that got lost in that translation was, if we were going to go
> down the path you are considering, I would be interested in the OT
> subsystem and the protocol.  The main reason I have not been contributing
> much is simply because we aren’t doing much in those areas.
>
>
>
>
> On 3/10/16, 6:37 PM, "Michael MacFadden" 
> wrote:
>
> >Looking over the doc is a good start, I think we could codify some
> additional things or principles that we would want to account for.
> >
> >Personally, my expertise lies in the OT system and the client to server
> messaging.  Both in the implementation and in the “why/how” of what is
> there now.
> >
> >One thing I would say is that the Client’s data model / rendering
> approach is fairly sophisticated in two regards.  First building any sort
> of rich text editor in the browser is some what difficult.  I am not sure
> that undertaking that particular effort, GWT or otherwise is going to be
> easy.  The rest of the UI could be easily redone quickly, but the editor
> would take months and months to do from scratch.  I think we would want to
> consider if we should be looking at using an existing editor that is out
> there.
> >
> >The other area where the UI is complex is in the performance aspect of
> it.  The wave UI is designed to load a ton of “blips”.  The content over
> time could become very, very long.  There was some measure of thought put
> into the current system to make rendering and eventing very fast to handle
> large conversations.
> >
> >Just a few thoughts.
> >
> >~Michael
> >
> >
> >
> >
> >On 3/10/16, 4:34 PM, "Thomas Wrobel"  wrote:
> >
> >>As always +1 to separation (speaking as a GWT person not having a clue
> >>how the server works).
> >>--
> >>http://lostagain.nl <-- our company site.
> >>http://fanficmaker.com <-- our, really,really, bad story generator.
> >>
> >>
> >>On 10 March 2016 at 14:32, Evan Hughes  wrote:
> >>> Hell all,
> >>>
> >>> please see the attached document for my own personal vision for the
> future
> >>> of wave,
> >>>
> >>>
> https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit?usp=sharing
> >>>
> >>>
> >>> Happy to receive any thoughts on any of the changes.
> >>>
> >>> Sincerely,
> >>> Evan Hughes
> >
>
>

Re: A Wavy Future

2016-03-10 Thread Michael MacFadden

Something that got lost in that translation was, if we were going to go down 
the path you are considering, I would be interested in the OT subsystem and the 
protocol.  The main reason I have not been contributing much is simply because 
we aren’t doing much in those areas.




On 3/10/16, 6:37 PM, "Michael MacFadden"  wrote:

>Looking over the doc is a good start, I think we could codify some additional 
>things or principles that we would want to account for.
>
>Personally, my expertise lies in the OT system and the client to server 
>messaging.  Both in the implementation and in the “why/how” of what is there 
>now.
>
>One thing I would say is that the Client’s data model / rendering approach is 
>fairly sophisticated in two regards.  First building any sort of rich text 
>editor in the browser is some what difficult.  I am not sure that undertaking 
>that particular effort, GWT or otherwise is going to be easy.  The rest of the 
>UI could be easily redone quickly, but the editor would take months and months 
>to do from scratch.  I think we would want to consider if we should be looking 
>at using an existing editor that is out there.  
>
>The other area where the UI is complex is in the performance aspect of it.  
>The wave UI is designed to load a ton of “blips”.  The content over time could 
>become very, very long.  There was some measure of thought put into the 
>current system to make rendering and eventing very fast to handle large 
>conversations.
>
>Just a few thoughts.
>
>~Michael
>
>
>
>
>On 3/10/16, 4:34 PM, "Thomas Wrobel"  wrote:
>
>>As always +1 to separation (speaking as a GWT person not having a clue
>>how the server works).
>>--
>>http://lostagain.nl <-- our company site.
>>http://fanficmaker.com <-- our, really,really, bad story generator.
>>
>>
>>On 10 March 2016 at 14:32, Evan Hughes  wrote:
>>> Hell all,
>>>
>>> please see the attached document for my own personal vision for the future
>>> of wave,
>>>
>>> https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit?usp=sharing
>>>
>>>
>>> Happy to receive any thoughts on any of the changes.
>>>
>>> Sincerely,
>>> Evan Hughes
>

Re: A Wavy Future

2016-03-10 Thread Michael MacFadden

Looking over the doc is a good start, I think we could codify some additional 
things or principles that we would want to account for.

Personally, my expertise lies in the OT system and the client to server 
messaging.  Both in the implementation and in the “why/how” of what is there 
now.

One thing I would say is that the Client’s data model / rendering approach is 
fairly sophisticated in two regards.  First building any sort of rich text 
editor in the browser is some what difficult.  I am not sure that undertaking 
that particular effort, GWT or otherwise is going to be easy.  The rest of the 
UI could be easily redone quickly, but the editor would take months and months 
to do from scratch.  I think we would want to consider if we should be looking 
at using an existing editor that is out there.  

The other area where the UI is complex is in the performance aspect of it.  The 
wave UI is designed to load a ton of “blips”.  The content over time could 
become very, very long.  There was some measure of thought put into the current 
system to make rendering and eventing very fast to handle large conversations.

Just a few thoughts.

~Michael

On 3/10/16, 4:34 PM, "Thomas Wrobel"  wrote:

>As always +1 to separation (speaking as a GWT person not having a clue
>how the server works).
>--
>http://lostagain.nl <-- our company site.
>http://fanficmaker.com <-- our, really,really, bad story generator.
>
>
>On 10 March 2016 at 14:32, Evan Hughes  wrote:
>> Hell all,
>>
>> please see the attached document for my own personal vision for the future
>> of wave,
>>
>> https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit?usp=sharing
>>
>>
>> Happy to receive any thoughts on any of the changes.
>>
>> Sincerely,
>> Evan Hughes

Re: A Wavy Future

2016-03-10 Thread Thomas Wrobel

As always +1 to separation (speaking as a GWT person not having a clue
how the server works).
--
http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.


On 10 March 2016 at 14:32, Evan Hughes  wrote:
> Hell all,
>
> please see the attached document for my own personal vision for the future
> of wave,
>
> https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit?usp=sharing
>
>
> Happy to receive any thoughts on any of the changes.
>
> Sincerely,
> Evan Hughes

Re: A Wavy Future

2016-03-10 Thread Upayavira

On Thu, 10 Mar 2016, at 01:32 PM, Evan Hughes wrote:
> Hell all,
> 
> please see the attached document for my own personal vision for the
> future
> of wave,
> 
> https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit?usp=sharing
> 
> 
> Happy to receive any thoughts on any of the changes.

My suggestion: find your own backwater in Git (a separate branch?) and
start working on it. It will be much easier for people to contemplate
real code than a (relatively) abstract idea. The project is under no
obligation to use this code, but I guess you'll hope they love it enough
to take it on.

Upayavira

A Wavy Future

2016-03-10 Thread Evan Hughes

Hell all,

please see the attached document for my own personal vision for the future
of wave,

https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit?usp=sharing


Happy to receive any thoughts on any of the changes.

Sincerely,
Evan Hughes

44 matches

Mail list logo