derstanding is that the core wave federation paradigms / protocol (and
the wiab federation implementation) suit mobile very well. They were
explicitly designed to support real-time when online, and disconnected
access when offline.
Someone please correct anything I've got wrong!
Dave
e have been a few discussions about formalising the
client/server protocols within wiab - but so far there hasn't been the
manpower to implement it.
Dave
On 29/05/13 03:30, John Blossom wrote:
Dave,
I think that you've captured much of both the paradigm and the paradox.
Wave could -
oject at the moment. Sort of organising the deckchairs
on the titanic? ;-)
Dave
is that those
order and ease improvements could be achieved equally well with Ant as
with Maven.
Making those order and structure changes to the codebase first without
changing the build system seems a more attainable goal.
Dave
Some point in the future: wave permissions, other clients etc. etc.
A switch to maven could fall in anywhere, and would be neat to have, but
imho I don't think it's required, or (in itself) going to make much
difference to our level of participation.
Dave
On 30/05/13 22:37, Bruno Gonzalez wrote:
On Thu, May 30, 2013 at 10:39 PM, Dave wrote:
- Cleanup. With a fresh checkout of svn earlier today, I experienced
(easily fixed) build failures and compiler errors, though I'm not sure if
these are purely related to my environment / jdk et
On 31/05/13 00:01, Dave wrote:
I'll raise a JDK7 ticket.
or just find the existing ticket:
https://issues.apache.org/jira/browse/WAVE-316
Dave
omponent
name as "wave" in wiab and openfire - the others I've made the same
assumptions as you.
- The xmpp_server_secret is the same pass word used in the
component_secret in prosody configuration, and not some xmpp-server-wide
password, right?
Yes, it's the password that wiab uses to authenticate itself as a
component in prosody.
Dave
ation with:
wave.glark.co.uk:9898
wave.daveball.org.uk:9899
I'm seeing connections, but it looks like my SSL config isn't correct
yet. I'll let you know once it's working...
Dave
l need us to use the same OT alogrithm (eventually), so
clarity on the pros/cons of keeping or changing the wave OT approach
would be a good first step in that direction!
Dave
Michael,
On 10/06/13 21:53, Michael MacFadden wrote:
Dave,
Thanks for your thoughts. A few things to consider. There is a
distinction between P2P messaging and P2P OT. A system could reasonable
have a client server messaging architecture where the server is a hub and
the clients are spokes
? But they could
equally plug into an OT capable client or server in a live-update aware
manner? I guess this isn't how you envisage these components talking to
each other - but it seems valid and perhaps even simpler?
Thanks again - I'm finding this really helpful to understand the
different perspectives across our communities. Hopefully this can help
draw us all closer!
Dave
d allow re-hosting of a wave if
the original host goes off line?
The underlying OT supports P2P style merging, and there are the
efficiency advantages of having OneTrueHost for a given wave, but if
that host goes offline the wave can be re-hosted elsewhere.
Dave
years back?
I've got lots of questions and very few answers, but hopefully we're
getting more clarity on what we want/expect from this community.
Dave
On 11/06/13 19:41, Michael MacFadden wrote:
In a sense yes. In a P2P model there is no single canonical wave. All
the federated s
ike services, but a number of
incompatible approaches. I'm thrilled by the goals of greater
collaboration between us - and was trying to understand what that means
in terms of wiab code.
Dave
On 11/06/13 21:28, Michael MacFadden wrote:
Dave,
I guess the question I would ask before going down
at
solid at the moment, so it might not go anywhere.
Dave
algorithm.
Protobuffs in XMPP might not be the most elegant wire protocol, but
they're both proven, solid messaging technologies. I can see appeal in
replacing them, but for my money the path of least resistance would be
to improve these implementations.
Dave
cture.
Sounds very positive!
Should we be considering such changes for the Apache Wave codebase?
Dave
On 12/06/13 01:10, Joseph Gentle wrote:
... Don't mind me - I get a little ranty :)
I've a thick skin ;-)
On 12/06/13 00:54, Joseph Gentle wrote:
On Tue, Jun 11, 2013 at 4:08 PM, Dave wrote:
Protobuffs in XMPP might not be the most elegant wire protocol, but they're
bot
ncepts we choose to keep.
Dave
A.
Everything as expected - 0.4 (or trunk) doesn't include Ali's latest
fixes, so federated live editing works, but with an immediate shiny.
0.4 isn't focusing on functionality so I'm +1, but if we for roll for
another RC it might be worth bringing those fixes over from A
onfiguration is unnecessarily painful.
Dave
think it's
worthwhile. There's a lot of XMPP specs and implementations that we
don't use, and our use of XMPP might be unusual, but I don't think it's
unreasonable.
Dave
pache wave to represent - which could be wider than the wiab codebase.
Dave
al modules and a
wee bit of code structure documentation would make it a lot easier for
new devs to jump in.
Dave
oach. It would
require making the existing code more modular, but doing any of this
work within wiab from early on would make sure that those module
boundaries and dependencies were properly defined and implemented.
Dave
+1
On 12/06/13 22:20, Vicente J. Ruiz Jurado wrote:
El 12/06/13 12:26, Paulo Pires escribió:
Why not simply try to improve what we already have, by modularizing
stuff, separate server from web client, documenting and providing
ways of people to develop their products on top of Wave? I for one a
Out of interest, how close does the Google Walkabout SLOB layer (Shared
Live Object) come to this?
Dave
On 14/06/13 09:39, Michael MacFadden wrote:
Bruno / Sam,
This is the tricky part. You can abstract "some" parts of the operation
but not all. The whole point of the OT S
is built on top of this, but the live
collaboration layer is flexible enough to support other applications.
It's apache licensed, and took at least some insperation from ShareJS.
Dave
[1] http://code.google.com/p/walkaround/
One of the things that always struck me in Wave was tha
are better visualised differently / separately.
Is there anything inaccurate or that should be added this diagram, and
is it worth including in the wiki?
Dave
and now as a link, rather than attachment:
http://i.imgur.com/gv4qMJY.png
On 16/06/13 17:11, Dave wrote:
I couldn't find an overview of the various bits of the wiab server,
and how they plumb together. So from a couple of hours digging into
the codebase, I knocked up the attached di
Sure - What tool would you suggest Yuri? I just used what was to hand -
OO Draw - but can upload the source somewhere?
For my education, what are the inaccuracies?
Dave
On 16/06/13 22:58, Yuri Z wrote:
It's not totally accurate IMHO. I would prefer some kind of mind map that
can be e
docs in svn?
I've not seen such documentation within a mindmap before, so I'm not
sure if that really achieves what I was aiming for. Happy to give
anything a try though.
Dave
On 17/06/13 00:28, Zachary “Gamer_Z.” Yaro wrote:
As an alternative, do Google Drawings support embedding?
My understanding is that the Robots API is exposed externally, but
WaveBus is an internal interface.
https://svn.apache.org/repos/asf/incubator/wave/trunk/src/org/waveprotocol/box/server/waveserver/WaveBus.java
Dave
On 18/06/13 13:53, John Blossom wrote:
Thanks for the diagram, Dave, it
9 if they can't find an appropriate SRV record.
Dave
On 22/06/13 17:46, Michael MacFadden wrote:
I guess that depends on what ports we set up to use and how the federation
works. I suppose it might be possible depending on how discovery works.
On 6/21/13 10:36 PM, "Fleeky Flanco&quo
e the five fields in
org.waveprotocol.wave.client.paging.AbstractTreeNode to be protected
(rather than private)
IIRC, that was sufficient to get it to build for me.
HTH
Dave
On 23/07/13 17:14, David Moore wrote:
Hello all,
My name is David Moore, and I'm a developer used to doing
- achieves some quick wins while avoiding any religious debate
Dave
On 09/05/11 10:35, Daniel Danilatos wrote:
Thanks for starting this survey.
I'd like to point out that still most of the "advantages" people are
listing are either vague or easily achievable without maven. We need
a
gt;>> Date: Sep 1, 2011 4:54 PM
> >>> Subject: short version of how to get started using Apache Wave-In-A-Box
> >>> To: ,
> >>>
> >>> This is all I was talking about. When someone googles "wave-in-a-box"
> >>> or "apach
Look at Tinkerpops. It will allow for several options through a single API
as well as several other tools .
http://tinkerpop.com/
build - where the current tree has them checked in.
It'd be worth trying to generate them with latest protoc to see if that
avoids the problem.
Dave
On 31/05/13 16:35, Paulo Pires wrote:
With Maven, I only had an issue (with source as 1.7, because 1.6 works nicely)
that I fixed w
, made sure it logged as I expected...
Thanks,
Dave Ball
ATION
Diff: https://reviews.apache.org/r/11597/diff/
Testing
---
Ran up the server, made sure it logged as I expected...
Thanks,
Dave Ball
Hi David,
This list uses self-service maintenance, i.e. you need to unsubscribe
yourself.
Just send an email to the unsubscribe address documented here:
http://incubator.apache.org/wave/mailing-lists.html
Dave
On 08/06/13 19:45, David van Eyssen wrote:
Unsubscribe please.
diting the same document at the same time (with unknown
wire latency), because the algorithm ensures the merge will happen in a
consistent way when all ends eventually catch up.
Dave
We already have confluence.
https://cwiki.apache.org/confluence/display/WAVE/Home
Dave
On 25/06/13 16:23, Upayavira wrote:
What wiki? Do we have one? If not, I can get one set up. We have a
choice of MoinMoin or Confluence.
Upayavira
On Tue, Jun 25, 2013, at 04:12 PM, John Blossom wrote
ript.
I'm not particularly familiar with the codebase, but I think there is
already an implicit assumption of these three parts - although at the
moment they are somewhat(!) interwoven in the same codebase.
Dave
ps - separating the document model and the concurrency model might also
be
le. Exposing the existing interface
(without worrying too much about improving it) seems like an excellent
initial step - and by making that interface more visible will hopefully
make it more obvious how we can improve it iteratively.
Dave
[1] I'm as guilty as many in doing plenty of talkin
+1
lgtm - tested simple install, user registration and local waves.
Dave
On 01/04/15 06:11, Yuri Z wrote:
RC7 is now available for review.
Artifacts can be found here:
*https://dist.apache.org/repos/dist/dev/incubator/wave/0.7-incubating/
<https://dist.apache.org/repos/dist/dev/incuba
+1
Tested simple local server, sign up, local waves, adding and removing
recipients.
Dave
On 15/04/15 01:08, Ali Lown wrote:
Aah. The closing time for this has snuck up on me. I will test this
out in the morning.
Seems like we could do with a few other people checking it as well though
I think one can infer "alpha" from the version number being 0.4.0, so
I'm not sure we need alpha in the build names. ()
0.4.0-RC8 seems clear to me for the folder name.
Dave
On 15/04/15 14:53, Yuri Z wrote:
Thanks for the comments Ali.
1 - This one is nasty, forgot to remove
Fantastic news! Congratulations all!
Lots of people have spent much time shepherding this release; I for one
am very grateful.
Thank you.
Dave
On 05/04/16 17:47, Yuri Zelikov wrote:
The Apache Wave community is pleased to announce 0.4.0-incubating release.
The source and binary release
I only exist in the peanut gallery, but this reflects my feelings too.
Wave isn't wave without federation... I wish I had the time to help :-(
Dave
On 07/04/16 16:42, Thomas Wrobel wrote:
I'm not sure there's any point in wave without federation frankly.
I supported wave b
t-of-the-box without
external components, rather than aiming for google-scale scalability in
the short term?
Dave
On 19/04/16 11:09, Pablo Ojanguren wrote:
Yuri, it's exciting to think on a blockchain decentralization approach, but
AFAIK blockchain is not suitable for such operation rat
deration,
but is there a problem with relying on FQDNs in the short term?
To me, it wouldn't seem problematic if we lost those aspects of the
current XMPP transport.
Dave
On 21/04/16 14:13, Yuri Z wrote:
I was thinking about IPFS, not sure if it does what we need.
On Thu, Apr 21, 20
54 matches
Mail list logo
