Good to know. Workaround PR is ready. I guess WAVE-312 is actually two
issues, the one I've fixed, no showing exceptions and other showing a
exception.
2017-04-30 22:09 GMT+02:00 Yuri Z :
> Yeah, I think it is an old one. In WiabPro they totally rewritten this part
> of client-server.
>
> On Sun,
Yeah, I think it is an old one. In WiabPro they totally rewritten this part
of client-server.
On Sun, Apr 30, 2017 at 10:50 PM Pablo Ojanguren wrote:
> Hi all,
>
> During user testing in SwellRT/JetPad I ran into a blocker bug. I've
> already open the issue [1]. It can be the same of other criti
Hi all,
During user testing in SwellRT/JetPad I ran into a blocker bug. I've
already open the issue [1]. It can be the same of other critical issues
(WAVE-312, WAVE-358)
I have already written a workaround in SwellRT and I will send PR to Wave
asap.
[1] https://issues.apache.org/jira/browse/WAVE
Just make
> sure to send the ICLA for companies.
>
> On Sun, Apr 5, 2015 at 10:47 AM Andrew Kaplanov
> wrote:
>
>> Hi Yuri!
>>
>> I think current client-server protocol is poorly designed.
>> - It mixes together getting of snapshots and opening of delta channel
sion.
> - Uploading of blips.
> - Raw data to optimize deserialization.
>
> I will be glad to commit new protocol if Kirill will agree.
>
>
> 2015-04-05 1:37 GMT+05:00 Yuri Z :
>
> > Hi
> > Let's us try to re-think the WIAB client-server protocol issue.
&g
Hi Yuri!
I think current client-server protocol is poorly designed.
- It mixes together getting of snapshots and opening of delta channels.
This eliminates reconnection possibility.
- All opened wavelet channels live in one protocol channel.
This makes difficult separated control of channels
ng into, seeing as someone has done it
already.
~~~
Thomas & Bertines online review show:
http://randomreviewshow.com/index.html
Try it! You might even feel ambivalent about it :)
On 4 April 2015 at 22:37, Yuri Z wrote:
> Hi
> Let's us try to re-think the WIAB client-server protoc
Hi
Let's us try to re-think the WIAB client-server protocol issue.
>From what I remember (please correct me if I am wrong) the client interacts
with server in four main ways:
1. Requests a snapshot on opening a wave
2. Sends deltas with updates
3. Receives deltas with updates.
4. I
Wiab cliet-server protocol is not corresponded to specification in
http://www.waveprotocol.org/protocol/design-proposals/clientserver-protocol.
It is specified in
src/org/waveprotocol/box/common/comms/waveclient-rpc.proto in the
distribtive.
Wiab.pro released
http://www.waveprotocol.org/protocol/de
WIAB is written in Java/GWT so there are no JS files in the source.
Client files are located under:
https://github.com/apache/incubator-wave/tree/master/src/org/waveprotocol/box/webclient
-
WIAB specific client stuff
https://github.com/apache/incubator-wave/tree/master/src/org/waveprotocol/wave/cli
Is there a good example of a client in the repository anywhere? I'm
trying to understand where the JS file(s) are that handle the
communication specifically (separate from the GWT ui?).
Also, I remember there being a command line client many moons ago, but
I'm foggy about that. Does that sti
I've drafted a modification of the "Wave Servers" page, and would like
feedback. Here's how the new text could look like (headers stripped):
For reference, the current version is here:
https://svn.apache.org/repos/asf/incubator/wave/site/trunk/content/wave/demo-servers.mdtext
#Mostly vanilla Wave
Many projects websites (and unix man pages) have sections with "See
also"/Related/Alternatives references. So even if wiab.pro is not a
vanilla wiab server (and even if rizzoma is not based on wiab code, or
sharejs, or kune, or whatever) we can still list them somewhere. We
simply have to make it c
On Thu, Jul 11, 2013, at 11:56 AM, Thomas Wrobel wrote:
> >> 2. Only servers that are satisfy the following conditions will be
> >> considered legitimate:
> >> a) WIAB based
> >> b) Free to use
> >> c) Actively contribute back to Apache Wave.
> >>
> >> I think such a solution will allow to grow t
>> 2. Only servers that are satisfy the following conditions will be
>> considered legitimate:
>> a) WIAB based
>> b) Free to use
>> c) Actively contribute back to Apache Wave.
>>
>> I think such a solution will allow to grow the Apache Wave community and
>> provide information about third party WI
On Thu, Jul 11, 2013, at 08:57 AM, Yuri Z wrote:
> I think Kirill raises here an important question - i.e. what should be
> the
> relations between the Apache Wave project and other WIAB based products.
> The issue is a bit tricky, because as I see it - Apache Wave cannot
> endorse
> or promote o
iewed client server protocol code.
>
> We going to update our http://wiab.pro instance with new code soon and we
> can commit this improvement into main tree. If you're agree to place link
> to our hosted instance http://wiab.pro on the
> http://incubator.apache.org/wave/
>
&g
Hello Developers,
We where fighting with frequent turbulences in wiab. And it is almost
finished with reviewed client server protocol code.
We going to update our http://wiab.pro instance with new code soon and we
can commit this improvement into main tree. If you're agree to place link
t
face now is probably
> > > > authentication. i've seen though that the c/s protocol doc doesn't
> > > explain
> > > > how auth should be handled.
> > > > my first idea is sending a simple pair of username and encrypted
> > password
> > &
ld be handled.
> > > my first idea is sending a simple pair of username and encrypted
> password
> > > that the server could check against and an ack/nack message from the
> > server
> > > to let the client know what's going on. what do you all think? is there
> >
what's going on. what do you all think? is there
> any
> > doc i'm missing that illustrates this?
> >
> >
> > D
> >
> > Il giorno 30 dicembre 2011 18:18, Michael MacFadden <
> > michael.macfad...@gmail.com> ha scritto:
> >
> >
t the client know what's going on. what do you all think? is there any
> doc i'm missing that illustrates this?
>
>
> D
>
> Il giorno 30 dicembre 2011 18:18, Michael MacFadden <
> michael.macfad...@gmail.com> ha scritto:
>
> > Davide,
> >
> > Aga
strates this?
D
Il giorno 30 dicembre 2011 18:18, Michael MacFadden <
michael.macfad...@gmail.com> ha scritto:
> Davide,
>
> Again, I am not an expert on the current client server protocol, but I do
> have one comment to make. I think a good objective of whatever protocol we
>
ok, i finally had time for reading your suggestions =)
repy is inline
> Hi David:
>
> First of all, I'm not a WIAB internals expert. But as I was patching the
> websocket part these months I can give you some advices:
> - WIAB now uses websocket (via jetty) for clients like chrome and
> socket-io
Davide,
Again, I am not an expert on the current client server protocol, but I do have
one comment to make. I think a good objective of whatever protocol we come up
with is that the protocol (i.e the message syntax, message semantics, data
types, etc) be separated from the transport layer. I
Thanks a lot for your help Vincente, I'll check everything and report back
:-)
D
Il giorno 30/dic/2011 01:34, "Vicente J. Ruiz Jurado"
ha scritto:
> El 29/12/11 20:30, Davide Carnovale escribió:
> > Hi all,
> > I'd like to contribute to apache wave, in particular in the c/s protocol
> > area, my
El 29/12/11 20:30, Davide Carnovale escribió:
> Hi all,
> I'd like to contribute to apache wave, in particular in the c/s protocol
> area, my ideal goal (in wave terms) is to make a working c/s protocol and
> an android API that could later be used to build any kind of wave clients.
> (because my g
Hi all,
I'd like to contribute to apache wave, in particular in the c/s protocol
area, my ideal goal (in wave terms) is to make a working c/s protocol and
an android API that could later be used to build any kind of wave clients.
(because my general goal, outside of wave scope, is to have a special
David,
I've had some time to become familiar with the current client/server protocol.
I'm fairly comfortable with the current protocol, and have created/hacked out a
client that is considerably different than the current client.
I'm excited to hear that there is/was a protocol
at might be
>> tricky but ultimately necessary.
>>
>>
>> I also think that not dealing with this issue, might be detrimental, it is
>> going
>> to get harder to do later, no?
>>
>>
>>
>>
>> From: Yuri Z
>>
at might be
> tricky but ultimately necessary.
>
>
> I also think that not dealing with this issue, might be detrimental, it is
> going
> to get harder to do later, no?
>
>
>
>
> From: Yuri Z
> To: wave-dev@incubator.apache.org
>
upport opening at particular versions, which is
>> >> required
>> >> >>>> for
>> >> >>>>> diff-on-open
>> >> >>>>> * it bundles state and deltas over the same channel, rather than a
>> >> >>>&g
ricky but ultimately necessary.
I also think that not dealing with this issue, might be detrimental, it is
going
to get harder to do later, no?
From: Yuri Z
To: wave-dev@incubator.apache.org
Sent: Tue, 19 July, 2011 22:06:25
Subject: Re: Client/Server pro
memory (something about
> closing
> >> >>>>> connections? or losing access because of a participant change?).
> >> Listing
> >> >>>>> the diff between the old and new protocol behaviour should produce
> a
> >
or losing access because of a participant change?).
> >> Listing
> >> >>>>> the diff between the old and new protocol behaviour should produce
> a
> >> >>>>> complete list.
> >> >>>>>
> >> >>>>>
; complete list.
>> >>>>>
>> >>>>> Hope that helps,
>> >>>>>
>> >>>>> -Dave
>> >>>>>
>> >>>>> On Sun, Jul 10, 2011 at 8:22 AM, Thomas Wrobel
&g
> ~~
> >>>>>> Reviews of anything, by anyone;
> >>>>>> www.rateoholic.co.uk
> >>>>>> Please try out my new site and give feedback :)
> >>>>>>
> >>>>>>
> >>>>>>
>
t;>>> On 9 July 2011 23:11, Thomas Wrobel wrote:
>>>>>>> Guess I could have a go at those - they seem client based stuff so I
>>>>>>> should be able to handle it.
>>>>>>> I'll download a new checkout now and have a look.
>&g
go at those - they seem client based stuff so I
>>>>>> should be able to handle it.
>>>>>> I'll download a new checkout now and have a look.
>>>>>>
>>>>>> However, Can I have confirmation of the state of that proposed c/s
>>
>
> >> >> > However, Can I have confirmation of the state of that proposed c/s
> >> >> > protocol however as Joseph didn't know?
> >> >> >
> >> >> > At he moment Im a guy that doesn't know how it works at t
hat proposed c/s
>> >> > protocol however as Joseph didn't know?
>> >> >
>> >> > At he moment Im a guy that doesn't know how it works at the moment,
>> >> > not knowing what exactly should be implemented/changed, and unsure if
>> >
> he has the skills needed to do it :p
> >> >
> >> > Perhaps I'm wrong, or being pessimistic, but at the moment I I feel
> >> > like I could fix 10-20 client side bugs or feature requests in the
> >> > time it will take me to understand ho
bugs or feature requests in the
>> > time it will take me to understand how the wiab client and server
>> > should communicate with eachother.
>> >
>> > -Thomas
>> >
>> >
>> >
>> > On 9 July 2011 19:40, Yuri Z wrote:
>> >&
gt;
> > -Thomas
> >
> >
> >
> > On 9 July 2011 19:40, Yuri Z wrote:
> >> A great way to familiarize yourself with WIAB is by comepleting
> >> StarterProject<
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+Sta
On Sat, Jul 9, 2011 at 8:19 AM, Thomas Wrobel wrote:
>
> David Hearnden there said;
>
> "I would strongly encourage not building too much on the current protocol,
> since it has a number of known limitations. The new protocol is simpler
> and
> achieves a better separation of functionality. "
>
On Sat, Jul 9, 2011 at 3:15 AM, Joseph Gentle wrote:
>
>
> The client and server talk by sending protobuf messages encoded as
> JSON over a socket.io connection. Protobufs are quite formally defined
> - so you can see what the messages look like by looking at a few
> files in the repository:
>
>
>As indeed is Apache :-)
without a doubt!
>I think there is a lot of potential in FSW; the hard part as always being
>identity and privacy.
certainly, i hope, eventually FreedomBox team with all the mighty
Debian hackers would solve
all the issues, i like that - their nonconformism combined with
sueNavigator.jspa?reset=true&jqlQuery=labels+%3D+StarterProject>
>> .
>>
>> 2011/7/9 Joseph Gentle
>>
>>> On Sat, Jul 9, 2011 at 8:19 AM, Thomas Wrobel wrote:
>>> >> As far as I know, the client-server protocol for wave in a box is
>>>
On 9 Jul 2011, at 20:24, ya knygar wrote:
> excuse me, it's https://apps.mozillalabs.COM/
> anyway - their recent work looks like from a great non-profit organization :)
As indeed is Apache :-)
Certainly there are a lot of real-time services and specifications around at
the moment that have OT
eset=true&jqlQuery=labels+%3D+StarterProject>
> .
>
> 2011/7/9 Joseph Gentle
>
>> On Sat, Jul 9, 2011 at 8:19 AM, Thomas Wrobel wrote:
>> >> As far as I know, the client-server protocol for wave in a box is
>> >> pretty stable at this point. Its d
excuse me, it's https://apps.mozillalabs.COM/
anyway - their recent work looks like from a great non-profit organization :)
On Sat, Jul 9, 2011 at 7:21 PM, ya knygar wrote:
> Scott Wilson,
> your
> https://github.com/scottbw/wave-node
> work and experience, W3C or WHATWG web apps working group wo
Scott Wilson,
your
https://github.com/scottbw/wave-node
work and experience, W3C or WHATWG web apps working group work,
and your contribution to XCCC could
really Help us all on developing a suitable for most format
for web-apps in Gadget's point-of-view,
in POW, since PyGoWave we had a number of v
As far as I know, the client-server protocol for wave in a box is
> >> pretty stable at this point. Its documented here:
> >>
> http://www.waveprotocol.org/protocol/design-proposals/clientserver-protocol
> >> ... Though that documentation is probably out of date.
>
On Sat, Jul 9, 2011 at 8:19 AM, Thomas Wrobel wrote:
>> As far as I know, the client-server protocol for wave in a box is
>> pretty stable at this point. Its documented here:
>> http://www.waveprotocol.org/protocol/design-proposals/clientserver-protocol
>> ... Thou
>I have to point out, none of these solutions are actually federated -
>and thus unsuitable for anyone wishing to make a open network where
>anyone can run a server.
WFP and WIAB was the highest! priority for pyofwave.info,
we could say - the PyOfWave was the only besides WIAB which
were aimed for
pport the same system is another step.
I wish them luck, but Id rather stick with whats here and now till
theres working superior alternatives.
> As far as I know, the client-server protocol for wave in a box is
> pretty stable at this point. Its documented here:
> http://www.waveprotocol.o
Not true. Or, not true for long. Some people are talking about putting
an open federation spec together:
http://piratepad.net/HET5ojzCXM
But thats still not really answering your question.
As far as I know, the client-server protocol for wave in a box is
pretty stable at this point. Its
s on the development of the project. I was only interested in
>> the OT part of it and it was not documented and lack of documented
>> client/server protocol didn't help! GWT was the final deal breaker :D
>>
>> But when I left wave for and started looking for something e
; many things on the way... but the one that took my attention was
> > http://opencoweb.org/
> >
> > An OT framework, both for Python and Java with a lot of documentation and
> a
> > well defined Javascript client API and a proper documented client/server
> API
> &
work with... but thats a long rant I won't bother with.
>>
>> I just keep tabs on the development of the project. I was only interested in
>> the OT part of it and it was not documented and lack of documented
>> client/server protocol didn't help! GWT was the final
rant I won't bother with.
>
> I just keep tabs on the development of the project. I was only interested in
> the OT part of it and it was not documented and lack of documented
> client/server protocol didn't help! GWT was the final deal breaker :D
>
> But when I left wa
Hi Rohit Rai!
thank you for the link,
very interesting, indeed.
please - post as much as possible from what you have discovered
into http://primarypad.com/OeMj2ZnZqo
it will, definitely, help Wave protocols to evolve.
documented
client/server protocol didn't help! GWT was the final deal breaker :D
But when I left wave for and started looking for something else, I found
many things on the way... but the one that took my attention was
http://opencoweb.org/
An OT framework, both for Python and Jav
I wondered if there was any interest again in helping push forward a
stable client/server protocol for wiab?
A few weeks back there was a thread started
(http://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201106.mbox/thread),
which then developed into a interesting discussion on
gt; version 5. Let sat that client 2's delta is applied first creating
> version
> > 6, then client 1's delta is applied creating version 7, and then client
> 3's
> > delta is applied creating version 8.
> >
> > If client 1 can expect:
> >
> >
ed after the submitted delta will not be
> delivered to the client prior to the actual submit response, then the client
> can use the versionAfterApplicationto distinguish between updates before and
> after the submitted delta.
...
I think that the client/server protocol should explici
On Mon, Dec 13, 2010 at 5:34 PM, Torben Weis wrote:
> Hi Tad,
>
> this problem was on my mind for a long time.
> Caching updates is not the ideal solution for interactivity and
> collaboration, because updates are unnecessarily delayed.
>
> What a client really needs is a way to detect its own de
on 8.
>
> If client 1 can expect:
>
>1. Update 6
>2. Submit response
>3. Update 8.
>
> then the client need not cache updates. If on the other-hand, client 1 has
> no guarantee of when the submit response will arrive, then it must cache
> updates until it k
68 matches
Mail list logo
