incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Hughes <ehu...@gmail.com>
Subject Re: A Wavy Future
Date Wed, 16 Mar 2016 01:18:52 GMT
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" <me@josephg.com> 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
> <michael.macfadden@gmail.com> 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" <pablojan@gmail.com> 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 <vega113@gmail.com>:
> >>
> >>> 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 <darkflame@gmail.com>
> 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 <vega113@gmail.com> 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 <darkflame@gmail.com
> >
> >>> > 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 <vega113@gmail.com>
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 <
> darkflame@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 <vega113@gmail.com>
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
<
> >>> > pablojan@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.
> >>> > >> >> >>
> >>> > >> >> >>
> >>> > >> >> >>
> >>> > >> >> >> 2016-03-14 23:27 GMT+01:00 Joseph Gentle
<me@josephg.com>:
> >>> > >> >> >>
> >>> > >> >> >>> 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
> >>> > <a_bielski@ymail.com.invalid
> >>> > >> >
> >>> > >> >> >>> 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 <
> >>> > zmyaro@gmail.com
> >>> > >> >> >>> > <javascript:;>> 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"
<vega113@gmail.com
> >>> > >> <javascript:;>>
> >>> > >> >> >>> 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 <
> >>> > >> >> wisebaldone@apache.org
> >>> > >> >> >>> > <javascript:;>>
> >>> > >> >> >>> > > 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.macfadden@gmail.com
<javascript:;>>
> >>> > >> >> >>> > > > 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 <
> >>> > >> >> >>> wisebaldone@apache.org
> >>> > >> >> >>> > <javascript:;>>
> >>> > >> >> >>> > > > 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.macfadden@gmail.com
<javascript:;>>
> >>> > >> >> >>> > > > > > 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 <
> >>> > >> >> >>> wisebaldone@apache.org
> >>> > >> >> >>> > <javascript:;>>
> >>> > >> >> >>> > > > > 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 <
> >>> > >> >> >>> > wisebaldone@apache.org <javascript:;>>
> >>> > >> >> >>> > > > > >> 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.org@flatline.de
<javascript:;>>
> >>> > >> >> >>> > > > > >>>>
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
> >>> > >> >> >>> > > > > >>
> >>> > >> >> >>> > > > >
> >>> > >> >> >>> > > >
> >>> > >> >> >>> > >
> >>> > >> >> >>> >
> >>> > >> >> >>> >
> >>> > >> >> >>>
> >>> > >> >> >>
> >>> > >> >> >>
> >>> > >> >>
> >>> > >>
> >>> >
> >>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message