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 Sat, 19 Mar 2016 08:55:06 GMT
Whats the best way we can collab on a protocol spec.

On Sat, 19 Mar 2016 at 07:05 Thomas Wrobel <darkflame@gmail.com> 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 <vega113@gmail.com> 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
> <a_bielski@ymail.com.invalid>
> > 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 <ehugh1@gmail.com> 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" <ehugh1@gmail.com> 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" <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