@pablo
you probably know the wave data model more than me, I should be on hipchat
for next 2hrs then afk for 8hrs then ill be back.
On Sun, 20 Mar 2016 at 21:18 wrote:
> 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
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 20
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 s
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 th
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 wa
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 w
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 sy
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
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 h
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 fro
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
c
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 cl
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?
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
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 imp
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
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 ra
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 a
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;
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 leas
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
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 massiv
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
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
develop
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
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
wrote:
> Yeah. Chatting is fine and beneficial. We just need to make sure we
> capture key decisions and rationale back in the list
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
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 conversatio
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
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
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
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 def
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 s
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 wrapp
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
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 De
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
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 th
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 doc
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 o
41 matches
Mail list logo
