Joseph's parenthetical comment basically sums up the reason I have been
doing things the way I have. I would love to see some larger wave
organization take over the Wave Extensions Gallery (
github.com/zmyaro/wave-extensions-gallery | waveextensions.org), but I do
not want to make it part of Apach
Michael,
Thanks very much for taking the initiative to make your statement. It is
for developers themselves to decide this, but I see some of the best
talents available beginning to coalesce around the Apache framework, now. I
agree that there are many good ideas on the table, and that there will
I agree, Joseph, just trying to give you a target to shoot at. I am here to
help you gain a market, and hopefully your decisions are market-worthy.
All the best,
John Blossom
email: jblos...@gmail.com
phone: 203.293.8511
google+: https://google.com/+JohnBlossom
On Wed, Jun 12, 2013 at 4:08 PM,
It should - the algorithms are the same. Whether or not it actually
works is another matter. I keep accidentally breaking ShareJS's
reconnection logic through tiny oversights.
-J
On Wed, Jun 12, 2013 at 4:51 PM, Zachary “Gamer_Z.” Yaro
wrote:
> I am pretty sure that was what was happening. I k
I am pretty sure that was what was happening. I know I used to edit waves
on my laptop on the bus (where there was no Internet connection) and ignore
the “Unsynced waves” message. When I got where I was going and connected
to the Internet, my waves would automatically sync and the warning would g
I love it. Well said, and I totally agree. (Although I still like
having ShareJS on Github.)
-J
On Wed, Jun 12, 2013 at 12:48 PM, Michael MacFadden
wrote:
> Wavers,
>
> It has become clear that there a MANY more people are interested in Wave
> that we had previously thought. There recent explo
The conversation *model* yes, but not the rich text documents
themselves. You can't really make text annotations work properly on
top of JSON operations. We should keep something like the current
system for actual blips.
-J
On Wed, Jun 12, 2013 at 4:06 PM, Michael MacFadden
wrote:
> Actually I
Actually I just went and took a look at your operations. The JSON OT type
is probably the closest to what I would suggest we use. JSON Objects are
not just for javascript. They define arbitrary objects structures. We
don't need a specific wave XML type, we could use the JSNO operations to
modif
What sort of operations do you have on the JSON OT type? That will help
me comment.
On 6/12/13 10:55 PM, "Joseph Gentle" wrote:
>Really?
>
>My method for ShareJS was to simply have a JSON OT type and a
>plaintext OT type. I'd like to add a rich text OT type as well. Then
>people can just pick w
On Wed, Jun 12, 2013 at 9:13 PM, Bruno Gonzalez (aka stenyak) <
sten...@gmail.com> wrote:
> I know it fixes some merging problems that most other DVCSs (like, at
> least, mercurial and git) suffer from. Not sure if it's the bestest dvcs in
> the world, but with regards to merging, it's certainly o
it would be nice to get things like rizzoma to be all the way open source
since they seem to have really attempted to make something useable out of
wave.
i think its a great idea to bring the code together and also the coders
actually working on wave in some form or another, its yet to be seen if
Awesome :D
As for the GWT vs JS thing, I think we could argue all day but we'll
be mostly trying to justify our personal preferences for languages. I
don't like java, but I can definitely understand why some people don't
like javascript. (And I do miss my IDEs).
I don't think we should bully cont
On Wed, Jun 12, 2013 at 10:08 PM, Joseph Gentle wrote:
> Thanks for your input, but this decision should be made by people who
> actually contribute code.
>
... or who may start contributing code, depending on the direction Apache
Wave takes from now on (if different from current one).
I've on
Really?
My method for ShareJS was to simply have a JSON OT type and a
plaintext OT type. I'd like to add a rich text OT type as well. Then
people can just pick which one based on what kind of data they have.
For Wave I'd like to be able to do something similar - JSON is
obviously useful for stori
On Wed, Jun 12, 2013 at 11:43 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:
> when the client goes
> offline, you can still edit. Operations are queued and then sent to the
> server when it is connected again.
>
Ah. Is this what really happened behind the curtains when the
googlewa
Yes you can. Do this. Although clunky, you could actually do this today.
As long as you can acquire the wave from the server to start writing it
(or if the api allowed you to create one locally), when the client goes
offline, you can still edit. Operations are queued and then sent to the
server
You have stumbled upon one of the weaknesses of wave OT. Best practices
would say to NOT bind your OT directly to the data type, because then you
don't have an extendable model. For example if you have all of your
operations figured out and validated, and then you need to change your
data model, y
-1 for moving away from GWT.
Gwt really does make heavily optimized Javascript - you would be hard
pressed to beat it by hand written Javascript in all but small
projects. Gwt starts fairly big for small things, but scales *very*
well.
The fact that the current Client is a bit heavy and messy isn't
On Mon, Jun 10, 2013 at 10:53 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:
>
> In terms of mobile devices, unless we are talking about some form of
> bluetooth or local wifi, then it is likely that messaging with be client
> server. However, how OT happens is up for debate.
>
Goin
Yeah exactly. The google wave OT code uses special operations that can
understand the XML structure. It doesn't just edit the plaintext.
Formatting annotations are stored in a special way - operations can
say something like "At position 10 add bold. At position 20 stop
adding bold".
-J
On Wed, Ju
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 am
> not interested at all in current web client fu
> Still here, still following and helping out in the background when Googley
> things arrive (hence the reason why I abstain my vote, great work though!)
Ok. I hadn't seen you for a while, so I wasn't sure of your status...
Is that a +0 though? (If so, please post on the VOTE thread). :)
Ali
On Sat, Jun 8, 2013 at 5:11 PM, Ali Lown wrote:
> Looking at the list of comitters for the wave project (including the
> PMC), I have seen on the list over the last few years:
>
> https://people.apache.org/committers-by-project.html#wavehttps://people.apache.org/committers-by-project.html#wave
>
All I can say is, "well said". We need to consider Wave as a young
project - one that really doesn't yet have anything set in stone.
I've heard Apache described as a 'do-ocracy', that is, he who does,
decides.
If there's an approach you think would be good, start coding, show us
your work (stick
I suspected something like that. I assume it also correctly handles
variable-length UTF8 characters, so it's not necessarily 1-byte patches?
This starts to make sense. OT can only compute conflict-free merges using
the "character" primitive (because that's how Wave was originally
designed). As an
On Wed, Jun 12, 2013 at 12:13 PM, Bruno Gonzalez (aka stenyak)
wrote:
> My assumption was that conflicts were simply mathematically inevitable in a
> DVCSs, that's why your mention about lack of conflict markers sparked my
> interest... you mention conflicts like they can be optional? If so, are
>
Let's not debate the details of the recommendation on this thread. I
would just like to hear from people doing wave type things and see if they
would be willing to join up with us. I feel like people aren't developing
here wave because they don't think their voices will be heard. If people
want
Thanks for your input, but this decision should be made by people who
actually contribute code.
-J
On Wed, Jun 12, 2013 at 12:08 PM, Pratik Paranjape
wrote:
> Two points John, someone has to speak for GWT :)
> GWT has its demerits (compilation time, monolithic output), but the 2
> mentioned abov
Dear Michael,
Can we start by moving on to Maven? It's a somewhat simple step
considering others this list has discussed lately. This would simplify
further separation of modules like OT, communication/protocol, clients, etc.
Also, IMHO multiple folders/projects on a repository will pollute the
I have been working on a geolocation (/augmented reality) specific Wave project:
arwave.org
I am not sure how suitable this is.
Its effectively a client that I (badly) want to be compatible with any
standard wave server.
As there was no standard client/server protocol for the last few
years, I gave
Wavers,
It has become clear that there a MANY more people are interested in Wave
that we had previously thought. There recent explosion of interest is
fantastic. However, what I am seeing is that the wave community is
splintered and fragmented. There are a lot of people who have been doing
deve
I mean types which have a TP2-capable transform & purge functions.
Same stuff I was talking about in the other thread.
-J
On Wed, Jun 12, 2013 at 12:15 PM, Michael MacFadden
wrote:
> Joseph,
>
> Can you clarify what you mean by "proper TP2 types".
>
> ~Michael
>
> On 6/12/13 6:22 PM, "Joseph Ge
PP,
Thanks, all very good points. I don't want to try to split the hair too
finely, but since compile time and object sizes are key factors in
perceived performance, perhaps there's some overlap there.
To your point, if we do have a GWT environment for an app, then it could be
used to develop cli
I think the point of decoupling the server from the client is the most
important one here as Yuri points out. After that, there doesn't need to
be an argument on which technology to build the client in. The community
will decided for itself by building whatever clients they like.
~Michael
On 6/
Joseph,
Can you clarify what you mean by "proper TP2 types".
~Michael
On 6/12/13 6:22 PM, "Joseph Gentle" wrote:
>Regardless of where the code goes, as I've said we should redesign the
>OT system using proper TP2 types. This will enable us to build a
>working federation protocol thats better a
On Wed, Jun 12, 2013 at 8:40 PM, Joseph Gentle wrote:
> On Wed, Jun 12, 2013 at 11:30 AM, Bruno Gonzalez (aka stenyak)
> wrote:
> > On Wed, Jun 12, 2013 at 8:19 PM, Joseph Gentle
> wrote:
> > I was under the impression that darcs could handle all edge cases that
> > even git can't handle (e.g.
Two points John, someone has to speak for GWT :)
GWT has its demerits (compilation time, monolithic output), but the 2
mentioned above are not among them.
1) GWT produces large output because that is the kind of projects it is
used for. No one uses GWT for average size website or general dom
manip
On Wed, Jun 12, 2013 at 11:30 AM, Bruno Gonzalez (aka stenyak)
wrote:
> On Wed, Jun 12, 2013 at 8:19 PM, Joseph Gentle wrote:
>
>> Yep. Similar but better, because using OT we can guarantee eventual
>> consistency we don't need conflict markers and there's a bunch of
>> edge cases darcs can't ha
To all,
I have been reading this thread carefully, and I am very appreciative of
the strong contributions from the community. This could go a number of
ways, obviously, but perhaps I can provide some focus, especially in light
of some specific projects that I am trying to get funded that could ben
On Wed, Jun 12, 2013 at 8:19 PM, Joseph Gentle wrote:
> Yep. Similar but better, because using OT we can guarantee eventual
> consistency we don't need conflict markers and there's a bunch of
> edge cases darcs can't handle.
>
> I was under the impression that darcs could handle all edge cases t
I think the point is, we need to work to each others strengths. Joseph
loves to work on js, and has awesome sharejs experience. Some others like
GWT, and there is a bunch of old code. Having not a huge community to
choose from, at least for now, if we can tune into our passions and let
everyone do
Yep. Similar but better, because using OT we can guarantee eventual
consistency we don't need conflict markers and there's a bunch of
edge cases darcs can't handle.
Likewise, the current OT algorithm we use is remarkably similar to
subversion/cvs. (We currently use a server-side version number th
Bruno,
Yes and know. The current federation protocol essential simulates only 1
server. When a client connects to a wave server that is not the server
where the wave originates, that server forwards ALL operations to the
authoritative wave server (the one that created the wave). All OT
actuall
On Wed, Jun 12, 2013 at 7:45 PM, Joseph Gentle wrote:
> Really? With the exception of google, I don't know of anyone who still
> uses GWT. The web is mostly moving to plain javascript. Amongst other
> things, a javascript web client would let us take the slow GWT
> compiles out of the edit-run lo
This sounds *awfully* similar to darcs patch theory. If the concepts are
the same, then all the theory is already worked out if i'm not mistaken.
http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory#Merging_is_symmetric
http://darcs.net/Theory
On Wed, Jun 12, 2013 at 7:39 PM, Joseph Gent
@Joseph My point was - the client is not that important, and in my opinion
it should be handled by improving Robot API instead of re-writing existing
native client.
However, the Federation issue is really important. It would be really great
if you could work out an prototype and then help us to por
I think there are a lot of people using GWT; just have a look at the
activity in the group.
I always wanted to participate more in Wave and it's future but TBH,
discarding Java and GWT will drastically reduce my interest... Just my 2c
2013/6/12 Joseph Gentle
> Really? With the exception of goo
Why not just use JSNI directly for interop? That lets us simply call
functions. Is it just so you don't have to recompile the GWT code when
you change the JS?
-J
On Wed, Jun 12, 2013 at 10:44 AM, Pratik Paranjape
wrote:
> There is a way to interop though. This is how I am doing it currently: GWT
Really? With the exception of google, I don't know of anyone who still
uses GWT. The web is mostly moving to plain javascript. Amongst other
things, a javascript web client would let us take the slow GWT
compiles out of the edit-run loop. It would also run faster & be
easier to optimize, it would l
There is a way to interop though. This is how I am doing it currently: GWT
creates a message bus on EntryPoint. Through JSNI, attaches an object in
the window with subscribe(), unsubscribe(), publish() api. The object acts
as a bridge between the two sides. MessageBus really is in GWT, but there
is
On Wed, Jun 12, 2013 at 7:32 PM, Yuri Z wrote:
> I actually like GWT in general and the fact that it allows to re-use the
> same OT code both on the server and client. Moreover, I think that the
> client is not that important, we just need to provide better Robot API and
> let people create their
Did you meet Torben at the wave summit? He took me through his way to
mitigate this problem. He describes it briefly here:
https://github.com/josephg/lightwave/blob/master/ot/README
In short, give every operation a unique hash. Each peer stores its own
(transformed) history list.
When two peers s
I actually like GWT in general and the fact that it allows to re-use the
same OT code both on the server and client. Moreover, I think that the
client is not that important, we just need to provide better Robot API and
let people create their own clients.
On Wed, Jun 12, 2013 at 8:22 PM, Joseph G
Regardless of where the code goes, as I've said we should redesign the
OT system using proper TP2 types. This will enable us to build a
working federation protocol thats better anyway. I also think we
should separate out the OT types into a library, and make the system
capable of hosting different
There's the #wiab channel registered at freenode. Feel free to join, though
as it's been mentioned several times, we'd better use IRC just for
fast-paced discussions, and later we have to reflect the conclussions back
in the mailing list.
On Wed, Jun 12, 2013 at 10:25 AM, Joseph Gentle wrote:
>
On Wed, Jun 12, 2013 at 6:38 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:
> Purely P2P OT is potentially infeasible for collaborations that are
> extremely long live and that have large numbers of collaborators. I
> included some rationale below.
>
> [...]
> Like I said this is an
Purely P2P OT is potentially infeasible for collaborations that are
extremely long live and that have large numbers of collaborators. I
included some rationale below.
That said, I can't imagine a use case where mobile devices will really do
OT with each other without a server. Unless we are talk
Thanks for the link Michael. Having a look. I really think we should go
HTTP. I thought of a model where two wave servers simply act as participant
in a different "system" wave, communicating over same protocol and tool
set. Riding our own horse instead of new external protocol. DNS can help
for re
http://www.waveprotocol.org/protocol/design-proposals/http-based-federation
-protocol
On 6/12/13 4:51 PM, "Pratik Paranjape" wrote:
>Has anyone actually thought over how it will be possible for something
>like
>wave to be P2P over HTTP? With security and data replication requirements?
>I don't
Has anyone actually thought over how it will be possible for something like
wave to be P2P over HTTP? With security and data replication requirements?
I don't see it myself :) Is this a direction many of us are thinking
(technically) about?
On Wed, Jun 12, 2013 at 9:10 PM, Pratik Paranjape wro
Understood, I didn't know federation was being tested in such conditions.
On Wed, Jun 12, 2013 at 5:39 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:
> XMPP would be involved when severs talk to each other. For servers in
> remote locations, this became a problem. I can not be mor
XMPP is what making servers federate in current code Bruno. Setting up
prosody etc...
http://wave-protocol.googlecode.com/hg/spec/federation/wavespec.html
On Wed, Jun 12, 2013 at 8:53 PM, Bruno Gonzalez (aka stenyak) <
sten...@gmail.com> wrote:
> Is XMPP involved in the connection of Mobile dev
XMPP would be involved when severs talk to each other. For servers in
remote locations, this became a problem. I can not be more specific due
to contractual considerations. Suffice to say that XMPP barely worked for
chat, let alone lively character by character collaboration.
On 6/12/13 4:23 PM
> 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 Ali's branch?
I had already
Is XMPP involved in the connection of Mobile devices in wiab or the defunct
google wave?
Or are you thinking about a future when wave has already become a P2P
software?
On Wed, Jun 12, 2013 at 5:16 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:
> The general consensus was that XMPP
The general consensus was that XMPP had to much overhead to be practical
in anything theory than highly connected environments for lively
collaboration. As bandwidth trails off, and/or you don't have persistent
TCP connections (I.e. Mobile devices). XMPP was killing the ability for
lively collabo
On 12/06/13 14:48, Yuri Z wrote:
But without XMPP you would need to define your own discovery protocol.
Yes. And implement alternatives for a couple of other bits such as
stream encryption, and anti-spoofing (such as dialback).
Nothing particularly tricky, although personally I don't think i
which I think should be our choice, there are good examples these days.
Servers can even register as service providers. XMPP is really not designed
for this application.
On Wed, Jun 12, 2013 at 7:18 PM, Yuri Z wrote:
> But without XMPP you would need to define your own discovery protocol.
>
>
>
But without XMPP you would need to define your own discovery protocol.
On Wed, Jun 12, 2013 at 4:47 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:
> Correct, it's just another configuration point.
>
> On 6/12/13 2:44 PM, "Dave" wrote:
>
> >On 12/06/13 12:43, Michael MacFadden wrote
Correct, it's just another configuration point.
On 6/12/13 2:44 PM, "Dave" wrote:
>On 12/06/13 12:43, Michael MacFadden wrote:
>> So, most people would not argue [against] XMPP as an established chat
>>protocol.
>> However, wave is not chat.
>
>Indeed. Xmpp is widely deployed for chat, but not w
On 12/06/13 12:43, Michael MacFadden wrote:
So, most people would not argue [against] XMPP as an established chat protocol.
However, wave is not chat.
Indeed. Xmpp is widely deployed for chat, but not widely deployed for
wave. Wave traffic is more noisy than simple chat, but the S2S
connectio
[ x] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0OK, but really should fix...
[ ] -1I oppose this release because...
(non binding)
I only tested the binary, ran up two instances - verified each
independently with two users on each, and then federated from A to B and
B to
You can even submit patches to ReviewBoard for the wave-git repo
On Wed, Jun 12, 2013 at 2:48 PM, Ali Lown wrote:
> There already exists a github mirror.
> Check https://github.com/apache/wave
>
> Ali
>
> On 12 June 2013 12:47, Pratik Paranjape wrote:
> > Not sure where Apache stands on this,
On 12/06/13 11:51, Michael MacFadden wrote:
Thanks. I agree with this perspective. When I started working with the
codebase, the nested levels of interfaces and implementations made it
impossible to trace through the code. Personally it seemed like
abstraction for abstraction sake. Yes.. It ma
+1
tested on Ubuntu 12.10.
On Sun, Jun 9, 2013 at 6:49 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:
> Posting the message on the right thread this time hopefully.
>
> I did test the latest RC on OSX. I also looked through the licensing and
> the packaging.
>
> +1
>
> ~Michael
>
>
There already exists a github mirror.
Check https://github.com/apache/wave
Ali
On 12 June 2013 12:47, Pratik Paranjape wrote:
> Not sure where Apache stands on this, but a Github mirror, even if read
> only, is likely to help to gain some visibility and possible contributions.
>
> The ease of na
Not sure where Apache stands on this, but a Github mirror, even if read
only, is likely to help to gain some visibility and possible contributions.
The ease of navigation and possibility of inspecting code without hassle
gets people interested. Big plus if we can accept pull requests there, but
I
Yes, for a chat client it is great. Messages in chart are much less
frequent. I am not sure XMPP is the best for character by character
operations.
One thing to note is that wave doesn't even "really" use XMPP as chat
programs do. XMPP Chat puts chat messages in XML. Wave uses XMPP as a
messag
Just a small comment; Facebook uses XMPP for its chat client too. Its
hardly industry toxic. In chat clients at least its practically
industry standard.
On 12 June 2013 12:14, Michael MacFadden wrote:
> A Googler once told me that XMPP was used primarily because they already
> had an internal inf
Thanks Michael.
I understand we will have to go through serious break and make. Current
code base is actually lethal at many places for performance and
scalability. Not updating UI until all operations are processed makes even
the basic experience sluggish. I think we need to find a clear plan for
haha, yes Ali. I was baffled to see so many layers of document model, for
really no practical advantage, only more confusion. Same with event
handling inside editor and IIRC ops model too. We should really be brave
and remove a bunch of unnecessary abstractions, and keep things simple.
That we shou
Whilst all the talk of rebuilding is good, can we get some more
reviews of the 0.4 release so we can get that released first...
Thanks.
Ali
On 9 June 2013 07:55, Christian Grobmeier wrote:
> Thanks Michael!
>
> Could you answer on the right thread? The problem is, IPMC people will
> look at the
Pratik,
Very good comments.
1) Personally, I think staying with Java is a good idea for the engine.
2) The OT Core is very special purpose for the wave conversation model.
Again, personally I would like to see it moved to a generic OT model, with
adaptation to the conversation model.
3) I am not
Question is: will we be able to sustain this enthusiasm long enough to
benefit from a clean slate? Code is in bad shape, agreed. There are better
options available today, agreed. But considering the scope, which is not
just OT, and but a whole platform to support services on top of
collaborative mo
Ali,
Thanks. I agree with this perspective. When I started working with the
codebase, the nested levels of interfaces and implementations made it
impossible to trace through the code. Personally it seemed like
abstraction for abstraction sake. Yes.. It made things fairly unit
testable, but main
> I agree. I think we need to look holistically at the code base. I
> honestly don't know what the best approach is. It sounds easy to say,
> let's just modularize it. I am not sure the current code base makes that
> possible in any meaningful way. The code is so abstract and intertwined,
> it
Hi,
one comment on the "graduation" aspect: basically it is not necessary
to release tons of artifacts to graduate.
My approach would be to continue with releasing the 0.4 package, there
is not harm done with that, even when the code base completely
changes.
The purpose is to "learn releasing".
T
PP,
I agree. I think we need to look holistically at the code base. I
honestly don't know what the best approach is. It sounds easy to say,
let's just modularize it. I am not sure the current code base makes that
possible in any meaningful way. The code is so abstract and intertwined,
it may
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 am not interested at all in current web client functionality, but
rather in the wave-model and
A Googler once told me that XMPP was used primarily because they already
had an internal infrastructure (Gtalk) based on XMPP, they just just
wanted to reuse this infrastructure. It does have its advantages in not
having to re-invent the wheel.
I can also say that in a few use cases, XMPP has pro
AFAIK the main idea of XMPP was to re-use the auto server discovery and to
use its secure communication. With lighter approaches - like HTTP you would
need to figure out how to relate a federating user from example.com domain
to the actual wave server that can run at sub domain wave.example.com.
Hello,
After some prompting by Zachary, I'm posting an idea here.
Based on my understanding of the Wave Conversation Model, each
participant of a wave had their own user-specific wavelet for that wave
that resided at the server hosting their user account, and this wavelet
was never federated (
I didn't realise that it was that messy, my apologies.
If its that intertwined I agree with starting again completely.
If we take that option might be worth considering if Java is the right
language. We may get more interest if we replace it with a 'cooler'
language like Python or Ruby.
Just my 2
Angus,
I think we all agree on that point. The question is how to do it. Try to
separate the current codebase (Option 1) or just start over (Option 2).
Trying to separate the current code base may not actually be feasible. It
MAY be quicker to just start over. I am not saying that it IS quicker
I think we need to separate the client from the server first of all. That
allows things like OT and federation to be ripped out and replaced whilst
leaving the client intact and slowly changing that if need be.
Thanks
Angus Turner
angusisf...@gmail.com
On Wed, Jun 12, 2013 at 7:28 PM, Michael Ma
Wavers.
It is a very positive sign that the Wave project has seen increase activity
in recent weeks. However, recent conversations point to the fact that we
are at a decision point with Apache Wave.
History
---
Google donated quite a bit of code to Apache for the Wave project. It is
somewh
On Wed, Jun 12, 2013, at 09:25 AM, Joseph Gentle wrote:
> On Wed, Jun 12, 2013 at 12:13 AM, Bruno Gonzalez (aka stenyak)
> wrote:
> > I agree with you on this. The other day I was about to add half a dozen new
> > settings to the config files (for the email-wave bot). I thought it would
> > take
On Wed, Jun 12, 2013 at 12:13 AM, Bruno Gonzalez (aka stenyak)
wrote:
> I agree with you on this. The other day I was about to add half a dozen new
> settings to the config files (for the email-wave bot). I thought it would
> take 5 minutes max, something like adding lines like this:
>
> value = s
On Tue, Jun 11, 2013 at 11:38 PM, Joseph Gentle wrote:
> I heard a story once from some developer attending a java conference.
>
> The theme was how to solve the challenges that Java faces in the next
> decade - and basically everyone was talking about how to make
> development tools scale up to
99 matches
Mail list logo
