Whats the best way we can collab on a protocol spec. On Sat, 19 Mar 2016 at 07:05 Thomas Wrobel <darkfl...@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 <vega...@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_biel...@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 <ehu...@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" <ehu...@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" <m...@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.macfad...@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" <pablo...@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 <vega...@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 < > darkfl...@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 <vega...@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 < > >> >> darkfl...@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 <vega...@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 < > >> >> 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 <vega...@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 < > >> >> >>> > 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. > >> >> >>> > >> >> >> > >> >> >>> > >> >> >> > >> >> >>> > >> >> >> > >> >> >>> > >> >> >> 2016-03-14 23:27 GMT+01:00 Joseph Gentle < > m...@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_biel...@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 < > >> >> >>> > zmy...@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" <vega...@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 < > >> >> >>> > >> >> wisebald...@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.macfad...@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 < > >> >> >>> > >> >> >>> wisebald...@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.macfad...@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 > < > >> >> >>> > >> >> >>> wisebald...@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 < > >> >> >>> > >> >> >>> > wisebald...@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....@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 > >> >> >>> > >> >> >>> > > > > >> > >> >> >>> > >> >> >>> > > > > > >> >> >>> > >> >> >>> > > > > >> >> >>> > >> >> >>> > > > >> >> >>> > >> >> >>> > > >> >> >>> > >> >> >>> > > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >> > >> >> >>> > >> >> >> > >> >> >>> > >> >> > >> >> >>> > >> > >> >> >>> > > >> >> >>> > >> >> > > >> >> > >> > > >> > >> >
