Re: [NOTICE] Wave is Retired - What's next?

[Michael MacFadden]

I think I have admin access to the old waveprotocol.org site if that helps. I 
can probably add people as admins.

~Michael

On 2/2/18, 2:05 AM, "Pablo Ojanguren"  wrote:

No idea either... I didn't use google sites before. First discussion in the
new group could be whether to move the site to other platform and update
the content :S

2018-02-02 10:28 GMT+01:00 Yuri Z :

> Yeah, I added you to the managers of the discussion group, regarding the
> waveprotocol.org that is a google site - I have no clue if I can add more
> admin users and how to do it.
>
> On Fri, Feb 2, 2018 at 10:55 AM  wrote:
>
> > I've just joined the google group. Yuri, do you want me to admin the
> group
> > too?
> >
> >
> > El 1 feb. 2018 5:49 p. m., Yuri Z  escribió:
> >
> > I still have admin access  to http://www.waveprotocol.org/, however, it
> > looks like the old discussion group was deleted by Google. I recreated 
it
> > from scratch. So, we can try to re-use it.
> > https://groups.google.com/forum/#!forum/wave-protocol
> >
> > On Thu, Feb 1, 2018 at 5:35 PM Upayavira  wrote:
> >
> > > Yes - that's gonna be a question for someone who was around when
> > > incubation was starting.
> > >
> > > Can you subscribe to those lists still?
> > >
> > > On Thu, 1 Feb 2018, at 2:50 PM, John D. Ament wrote:
> > > > Zachary,
> > > >
> > > > Unfortunately, I don't have an answer for you on that.
> > > >
> > > > John
> > > >
> > > > On 2018/01/27 18:59:09, Zachary Yaro  wrote:
> > > > > I do not recall getting an answer to this before: do we still have
> > > access
> > > > > to the old (pre-Apache) mailing list?
> > > > >
> > > > > Zachary Yaro
> > > > >
> > > > > On Jan 27, 2018 10:53, "Upayavira"  wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Sat, 27 Jan 2018, at 2:34 PM, John D. Ament wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I missed sending the notice to this list, apologies.  The vote 
to
> > > retire
> > > > > > Wave has passed.
> > > > > >
> > > > > > I'm going to begin the process of marking source code as read
> only,
> > > as
> > > > > well
> > > > > > as shutting down the lists.
> > > > >
> > > > > John,
> > > > >
> > > > > Would it be possible to schedule the list shutdown at a fixed 
point
> > in
> > > the
> > > > > future? e.g. 1week?
> > > > >
> > > > > Then those that remain here have that time to arrange a new venue
> for
> > > > > communication. If no such discussion happens - so be it, but at
> least
> > > there
> > > > > was a window for that discussion.
> > > > >
> > > > > Upayavira
> > > > >
> > >
> >
> >
>

Re: [VOTE] Retire Wave

[Michael MacFadden]

+1

On 1/1/18, 2:51 PM, "Upayavira"  wrote:

Wave is currently in the Apache Incubator, which has expectations of how a 
project matures. Wave, being a small project, over its seven years of 
incubation, is not showing signs of reaching graduation. Thus, it seems time we 
accept that the Incubator is not the place for this project.

Retirement need not halt development - it simply means that Apache is not 
the venue, and the project is relieved of the constraints and demands that 
Apache places upon it. Once retired, anyone can push the project code, for 
example, to GitHub. All that is required is that the terms of the Apache 
License continue to be honoured.

If the vote is to retire, then before actioning the retirement, we can have 
a discussion on this list to see if we can reach a consensus as to where the 
code might move to, or to see if there is a volunteer who is willing to carry 
out the migration work.

This vote is really aimed at members of the Wave PPMC, however general 
votes are welcomed.

[ ] +1 Retire Wave
[ ] 0 Abstain
[ ] -1 Keep Wave in the Apache Incubator

Upayavira

Re: SwellRT update

[Michael MacFadden]

Pablo,

+1 on this approach. I think this is the best idea if we can pull it off.

~Michael

On 3/21/17, 8:30 AM, "Pablo Ojanguren"  wrote:

At this moment I don't see Wave as a downstream dependency of SwellRT.
(SwellRT depending on Wave, right?)
SwellRT has modified Wave in different parts, so there is not a clear
separation of responsibilities right now.

Personally I would rather Wave to take over SwellRT entirely and liberate
Wave from the current GUI and become something generic. Then I would work
on Wave primarily, keeping SwellRT as a fork with maybe very specific
customizations to support jetpad.












2017-03-20 21:27 GMT+01:00 Upayavira :

> Pablo,
>
> Do you see Wave's copy of SwellRT as a fork? Or perhaps as a downstream
> dependency of SwellRT? How do you see the SwellRT team collaborating
> with Wave?
>
> Upayavira
>
> On Mon, 20 Mar 2017, at 03:25 PM, Pablo Ojanguren wrote:
> > ICLAs from original copyright owners of SwellRT source code has been
> > signed
> > and sent to Apache. This implies, AFAIK that Wave community is free
> > (libre)
> > to use SwellRT's source code entirely or parts of it without risks of
> > raising any IP issues. This makes safer, legally speaking, any
> > collaboration between communities involving the source code.
> >
> > This doesn't imply any commitment from Wave taking over SwellRT source
> > code, roadmap...and in particular SwellRT brand, that is a separated
> > matter.
> >
> > How SwellRT source code can be exploited by Wave is a community choice. 
I
> > think those more technically involved in the project should address the
> > discussion. My email is a part of this aim. I expect your point of view
> > so
> > we can define a tech road map.
> >
> >
> >
> >
> >
> > 2017-03-20 15:04 GMT+01:00 Evan Hughes :
> >
> > > Thanks for all the info but doesn't quite answers some of the more
> pressing
> > > questions.
> > >
> > > Has swellrt been donated to the incubator as in the incubator is now
> where
> > > the official swellrt development will happen? Does this include the
> > > branding asset's? How do we want to handle publishing of the swellrt
> as a
> > > sub part of this project.
> > >
> > > ~ Evan
> > >
> > > On 20 Mar 2017 11:22 PM, "Pablo Ojanguren"  wrote:
> > >
> > > Hi all,
> > >
> > > My apologies for the late update on SwellRT. I hope this email could
> help
> > > to clarify the ongoing discussion.
> > >
> > > As summary SwellRT objective is to make Wave generic...
> > >
> > > Instead of Wave Conversations it provides generic Collaborative
> Objects.
> > > Instead of a GUI it provides an API.
> > >
> > > *Current status:*
> > >
> > > *JavaScript Beta client*
> > >
> > >- Based on the original Web client.
> > >- No dependencies with GWT UI components.
> > >- No dependencies with JSNI thanks to JSInterop.
> > >- It allows to mutate and sync Javascript objects (ES6 Proxies).
> > >- This implementation is expected to ease generation of Android and
> iOS
> > >clients.
> > >- Basic features are in place but some others are still not 
migrated
> > >from alpha.
> > >
> > > Check out README[1] and Wiki[2] for usage details. To dive into the
> code,
> > > see package *org.swellrt.beta,* and the classes
> > > *ServiceFrontendEntryPoint*
> > > and *SObjectRemote*
> > >
> > >
> > >
> > > *Collaborative Editor Component*
> > >
> > > Task to provide the Wave text editor as a separated component, so
> > > eventually it could be replaced. So far, it exposes following features
> as
> > > API
> > >
> > >- Annotations
> > >- User presence
> > >
> > > Currently I am debugging it for mobile browsers.
> > > Widgets API coming soon.
> > >
> > > Package org.swellrt.beta.client.js.editor [3]
> > >
> > > *Federation with Matrix.org*
> > >
> > > Testing the proposed implementation [4] from GSoC'16 student. We would
> like
> > > to provide a PR asap.
> > >
> > >
> > >
> > > *JetPad*
> > > We are developing SwellRT together with a real application of it,
> > > jetpad.net
> > > [5] a collaborative text editor.
> > >
> > >
> > >
> > > *Google Sumer of Code 2017*
> > > We are also participating in GSoC17 thanks to the support of
> Universidad
> > > Complutense de Madrid and Berkman Klein Center (Harvard)
> > > Please encourage any students to send proposals, not limited to our
> > > suggestions [6]. 

Re: To-do's for graduation

[Michael MacFadden]

Hello all,

I know there has been some email traffic on this recently, but I think we 
should also prepare a little section in the wiki that talks about the people in 
the project.  Who would be the committers, the PMC, etc. Essentially who are 
going to be the initial active participants of the TLP. We have a lot of 
committers here from 4 years ago that have moved on to other things and don’t 
have time to.. My understanding in general for a TLP is that committers don’t 
always equal PMC; but that for a small set of committers that may be the case.

Regardless, I think one task is to identify who will really be part of the TLP 
and in what capacity.

I would be happing to work on this though interaction on the mailing list.

~Michael

On 3/11/17, 2:40 AM, "Pablo Ojanguren"  wrote:

That todo list LGTM
Thanks Evan

2017-03-10 1:04 GMT+01:00 Evan Hughes :

> Hello all,
>
> I think it's time for us to make a fixed set of tasks we want done before
> we go for graduation.
>
> To start off the list we must complete all the usual org tasks. This
> includes license checking, notice checks, crypto notice.
>
> Please respond to this with dot points of tasks you think should be on our
> todos before grad and they will latter be compiled into our confluence for
> the time being (maybe on website in the future). This will then transition
> to issues and may be assigned to individuals to complete before the next
> report.
>
> Just to state clearly, anyone is able to make a suggestion, don't limit
> suggestions to small tasks that are able to be completed before the next
> Incubator report.
>
>
> Todo List:
>
> * Publish the svg of logo on website.
> * Update incubator logo to use the new one (will be released shortly).
> * Remove any unesscary dependencies in repo.
> * Vote to decide on keeping the android client or to purge the repo.
> * Make an updated binary release after all changes made.
> * Clean the repository.
> * Docker file.
>

Re: SwellRT tech overview

[Michael MacFadden]

Upayavira,

+1

We have a lot of folks (myself included) who are very interested in wave, but 
aren’t actively developing.  We need to show the SwellRT folks that we have 
something to offer from a contribution standpoint (e.g. coding, design, 
documentation, etc.). If we can bring them some extra oomph, and the legal 
structure of apache is also appealing to them, then and only then does it make 
sense to move.  To that end, I might encourage the SwellRT team to start trying 
out some apache like behaviors.  E.g. using a mailing list for decision making 
and voting, etc. to see how they like it.

Thoughts?

~Michael

On 10/10/16, 4:14 PM, "Upayavira"  wrote:

I'm suggesting that before we go to the proposal phase, people just
start participating in SwellRT. Just do it. Let's see what you can all
accomplish over there - let SwellRT see what they have to gain, and let
Apache see how more vibrant and active SwellRT is as a community. Then
it will be a no-brainer for Apache to accept SwellRT.

Upayavira

On Mon, 10 Oct 2016, at 10:10 PM, Adam John wrote:
> Sorry to have missed you, Thomas.
> 
> "Cant a date be set, a vote be taken, then either import SwellRT or not?"
> According to Upayavira there should be a proposal.
> 
> This is what I've found: http://incubator.apache.org/guides/proposal.html
> Although this seems more targeted to new projects.
> 
> So the process would be:
> (1) Create a proposal
> (2) Submit it to the group via email
> (3) Vote
> 
> I've created this working document
> 

> to get us started - but not sure if the template at the link above is
> suitable.
> 
> Talk soon!
> 
> AJ
> 
> Adam John
> (914) 623-8433
> Google+  | LinkedIn
> 
> 
> On Mon, Oct 10, 2016 at 5:00 PM, Thomas Wrobel 
> wrote:
> 
> > I am sorry I didn't make the meeting, glade to see it was productive.
> > However, I am curious though why there is questions still as to if
> > SwellRT should be merged with wave.
> >
> > Wave development at apache is nearly dead.
> > Doing nothing and it will have to retire. No one has proposed a 3rd
> > option that I am aware of.
> > So in terms of community engagement, not seeing a downside.
> >
> > If theres technical downsides, thats another mater. But not aware
> > anyones raised any yet.
> > From what I have seen possibly my only concern is the API to
> > communicate to the server is just in javascript - we would
> > eventually need alternatives if we want to allow native iOS and
> > Android clients.
> >
> >
> > "activity similar to this starts brewing and
> > then it all dies down in a few months"
> >
> >
> > True. Seen it many times.
> > Maybe too much discussion with too little actual discussions resulting
> > in anything changing.
> > Cant a date be set, a vote be taken, then either import SwellRT or not?
> >
> >
> >
> > --
> > http://lostagain.nl <-- our company site.
> > http://fanficmaker.com <-- our, really,really, bad story generator.
> >
> >
> > On 6 October 2016 at 18:21, Pablo Ojanguren  wrote:
> > > Thanks Adam for clarifying the questions.
> > >
> > > Also I agree with Upayavira, the primary discussion it might be more
> > about
> > > "ideas" and the community's "engagement" with them. After that, tech
> > > aspects would come.
> > >
> > > So, in this regard I would like to share some thoughts about SwellRT 
as a
> > > product...
> > >
> > > a) Where SwellRT fit in the market? Competitors?
> > >
> > > SwellRT current vision is closer to products like Firebase, Meteor and
> > > Realm.
> > > They are new breed of frameworks/platforms to write apps. They 
provide as
> > > key feature, real-time data storage with simple document-based data
> > models.
> > > Their aim is to simplify and speed up web/app development. And of 
course,
> > > they allow to build real-time collaboration features easily.
> > >
> > > Of course, these projects are matured, but they still have pros and 
cons.
> > > What it seems clear to me is the trend: to develop heavier 
apps/webapps
> > > (because nowadays devices have a lot of computing power and it means 
just
> > > coding for one system)  and lighter backends providing common 
"services"
> > > (notifications, storage, auth...).
> > >
> > >
> > >
> > > b) What Wave/SwellRT's tech could offer in this market as innovation?
> > > Wave/SwellRT could compete with features like:
> > >
> > > - Open Source and JVM world: I guess 

Re: ALL HANDS - 9/28 10am EST

[Michael MacFadden]

d.  While not answered conclusively, I
    > > think it
> > >> is safe to expect the retirement will be held off *for now*.
> > >>
> > >> This meeting is about the future of Wave.
> > >> If you care about the project *at* *all*, *please join us*.
> > >>
> > >> Requested attendees:
> > >>
> > >>1.
> > >>
> > >>Price Clark
> > >>2.
> > >>
> > >>Thomas Wrobel
> > >>3.
> > >>
> > >>Evan Hughes
> > >>4.
> > >>
> > >>Zachary Yaro [cannot attend]
> > >>5.
> > >>
> > >>**Everyone on this list!**
> > >>
> > >> Confirmed:
> > >>
> > >>-
> > >>
> > >>Andreas Kotes
> > >>-
> > >>
> > >>Greg Cochard
> > >>-
> > >>
> > >>Jonathan Leong
> > >>-
> > >>
> > >>Pablo Ojanguren
> > >>-
> > >>
> > >>Michael MacFadden
> > >>-
> > >>
> > >>Adam John
> > >>
> > >>
> > >> Purpose:
> > >>
> > >> Overall the meeting is to establish some priorities and help plan the
> > >> project and move us forward.
> > >>
> > >> Please allot 1 hour for the meeting, but the target will be to wrap 
up
> > >> the agenda within 45 minutes.  Attendance will be taken, and a Google
> > Doc
> > >> for notes will be shared at the start for everyone to contribute.  
The
> > >> notes will also be sent out to everyone on the list.
> > >>
> > >> Agenda:
> > >>
> > >> Opening
> > >>
> > >> * Welcome, introduction of attendees
> > >>
> > >> * What is WAVE aiming to achieve?
> > >>
> > >> * Why is it important?
> > >>
> > >> Planning
> > >>
> > >> * Discuss option to bring swellrt into wave - expect result in "yes"
> or
> > >> "no" if possible
> > >>
> > >>* What does SwellRT solve?
> > >>
> > >> * Project Model Updates; New Client? (y/n/punt) New Server? 
(y/n/punt)
> > >>
> > >> * “The Wavy Future” reference document by Evan Hughes (gdoc link
> > >> <https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEh
> > XGucNZE04r_oA4/edit#>
> > >> )
> > >>
> > >> * Move federation from XMPP to Matrix code / needs a deep peer review
> > (github
> > >> link <https://github.com/Waqee/incubator-wave>)
> > >>
> > >> * Status of SwellRT development contest participation (website link
> > >> <http://swellrt.org/contest/>)
> > >>
> > >> * Identify additional Project Model updates, if any
> > >>
> > >> Conclusion
> > >>
> > >> * Wrap up and finalize priorities for work that needs to be done next
> > >> based on planning discussion - result will be captured in document.
> > >>
> > >> Please add/change this agenda as you see fit. (gdoc link
> > >> <https://docs.google.com/document/d/11j_
> WQGYAtDlN8Wqx8jJglPpw6tJznvMGf
> > dLOvQu96i0/edit?usp=sharing>
> > >> )
> > >>
> > >> Thanks, everyone!
> > >>
> > >> Adam John
> > >> (914) 623-8433
> > >> Google+ <http://google.com/+AdamJohn1> | LinkedIn
> > >> <http://mradamjohn.com/>
> > >>
> > >>
> > >
> >
>
>
> --
> Zachary Yaro
>

Re: Retirement

[Michael MacFadden]

;
> >> > WebCMS, Jira, Jenkins, and Travis are all valuable tools, and part of
> >> > Incubator status.
> >> >
> >> > Quality code review (thanks, vega and wisebaldone etc) and an
> established
> >> > process for the inclusion of new contributions by people familiar 
with
> >> > existing approaches and the work in progress... all of this is
> >> significant.
> >> >
> >> > The people on this list - and even the list itself - both a service
> and
> >> an
> >> > organization that would be a significant loss in any transition...
> >> >
> >> > I think the safety of the incubator is important, for these reasons
> and
> >> > more; and there needs to be improved communication, planning and
> >> > coordination... here again, just my opinion.
> >> >
> >> > AJ
> >> >
> >> > Adam John
> >> > (914) 623-8433
> >> > Google+ <http://google.com/+AdamJohn1> | LinkedIn <
> >> http://mradamjohn.com/>
> >> >
> >> > On Tue, Aug 30, 2016 at 4:01 PM, Upayavira <u...@odoko.co.uk> wrote:
> >> >
> >> >> The best future for Wave at Apache would, I think be to start an
> >> >> entirely new project at GitHub, and implement a Wave system that
> people
> >> >> can actually understand. Once that gains traction, come back to the
> >> >> Incubator and ask to resurrect Apache Wave with that new codebase.
> >> >>
> >> >> The current codebase seems to be simply too complex for people to be
> >> >> able to pick up. The idea stands as a good one, but the code is just
> too
> >> >> complex.
> >> >>
> >> >> Upayavira
> >> >>
> >> >> On Tue, 30 Aug 2016, at 09:58 PM, Taylor Fahlman wrote:
> >> >> > I've been a reader of this list for a while. I am another one of
> the
> >> >> > people
> >> >> > who would love to contribute, but literally have no idea where to
> >> start.
> >> >> > I
> >> >> > really think that if the code was divided a bit more it'd be
> easier to
> >> >> > contribute, because I want to see this project keep going. It
> really
> >> does
> >> >> > have a lot of potential in the current climate of silo-ed
> >> communication
> >> >> > systems. An easy docker image would really help too.
> >> >> >
> >> >> > On Tue, Aug 30, 2016 at 12:54 PM Thomas Wrobel <
> darkfl...@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> > > While the code will always be there in some form, is there any
> real
> >> >> > > hope outside of Apache though? will it not just fizzle out?
> >> >> > > Apache provides somewhat needed pressure, structure and to some
> >> extent
> >> >> > > even prestige.
> >> >> > >
> >> >> > > While retirement is understandable necessity for things without
> >> >> > > progress, its nevertheless sad for a project with such 
potential.
> >> Is
> >> >> > > it possible to put a call out for developers? a last warning? a
> >> >> > > advert? something beyond this list?
> >> >> > > I have no idea what form it would take though. I am so ignorant
> with
> >> >> > > big projects, both socially and structurally. Theres tools out
> there
> >> >> > > supposed to help motivate and organised (www.teamily.com) dont
> know
> >> >> > > how effectively they are though.
> >> >> > >
> >> >> > > It just all seems such a waste for wave to die, its death
> marking a
> >> >> > > little lost hope for the open web to recover some ground from 
the
> >> >> > > closed hubs that dominate today.
> >> >> > >
> >> >> > > --
> >> >> > > http://lostagain.nl <-- our company site.
> >> >> > > http://fanficma

Re: Retirement

[Michael MacFadden]

> more; and there needs to be improved communication, planning and
>>>> coordination... here again, just my opinion.
>>>> 
>>>> AJ
>>>> 
>>>> Adam John
>>>> (914) 623-8433
>>>> Google+ <http://google.com/+AdamJohn1> | LinkedIn
>>>> <http://mradamjohn.com/>
>>>> 
>>>>> On Tue, Aug 30, 2016 at 4:01 PM, Upayavira <u...@odoko.co.uk> wrote:
>>>>> 
>>>>> The best future for Wave at Apache would, I think be to start an
>>>>> entirely new project at GitHub, and implement a Wave system that
>> people
>>>>> can actually understand. Once that gains traction, come back to the
>>>>> Incubator and ask to resurrect Apache Wave with that new codebase.
>>>>> 
>>>>> The current codebase seems to be simply too complex for people to be
>>>>> able to pick up. The idea stands as a good one, but the code is just
>> too
>>>>> complex.
>>>>> 
>>>>> Upayavira
>>>>> 
>>>>>> On Tue, 30 Aug 2016, at 09:58 PM, Taylor Fahlman wrote:
>>>>>> I've been a reader of this list for a while. I am another one of the
>>>>>> people
>>>>>> who would love to contribute, but literally have no idea where to
>> start.
>>>>>> I
>>>>>> really think that if the code was divided a bit more it'd be easier
>> to
>>>>>> contribute, because I want to see this project keep going. It
>> really does
>>>>>> have a lot of potential in the current climate of silo-ed
>> communication
>>>>>> systems. An easy docker image would really help too.
>>>>>> 
>>>>>> On Tue, Aug 30, 2016 at 12:54 PM Thomas Wrobel <darkfl...@gmail.com
>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> While the code will always be there in some form, is there any
>> real
>>>>>>> hope outside of Apache though? will it not just fizzle out?
>>>>>>> Apache provides somewhat needed pressure, structure and to some
>> extent
>>>>>>> even prestige.
>>>>>>> 
>>>>>>> While retirement is understandable necessity for things without
>>>>>>> progress, its nevertheless sad for a project with such
>> potential.  Is
>>>>>>> it possible to put a call out for developers? a last warning? a
>>>>>>> advert? something beyond this list?
>>>>>>> I have no idea what form it would take though. I am so ignorant
>> with
>>>>>>> big projects, both socially and structurally. Theres tools out
>> there
>>>>>>> supposed to help motivate and organised (www.teamily.com) dont
>> know
>>>>>>> how effectively they are though.
>>>>>>> 
>>>>>>> It just all seems such a waste for wave to die, its death marking
>> a
>>>>>>> little lost hope for the open web to recover some ground from the
>>>>>>> closed hubs that dominate today.
>>>>>>> 
>>>>>>> --
>>>>>>> http://lostagain.nl <-- our company site.
>>>>>>> http://fanficmaker.com <-- our, really,really, bad story
>> generator.
>>>>>>> 
>>>>>>> 
>>>>>>>> On 30 August 2016 at 21:41, Upayavira <u...@odoko.co.uk> wrote:
>>>>>>>> Michael,
>>>>>>>> 
>>>>>>>> As I said earlier in this thread, retirement means the closure
>> of an
>>>>>>>> "apache" community. The code is already open source. So long as
>> the
>>>>>>>> trademark and the Apache License V2 on the code are respected,
>> as
>>>>> now,
>>>>>>>> anyone is free to do what they like with the code.
>>>>>>>> 
>>>>>>>> Thus, if someone (or someones) wanted to move it to Github,
>> that'd be
>>>>>>>> fine. I'm sure Apache wouldn't object to them using the name
>> "Wave"
>>>>> in
>>>>>>>> some form.
>>>>>>>> 
>>>>>>>> Upayavira
>>>>>>>> 
>>>>>>>>> On Tue, 30 Aug 2016, at 08:54 PM, Michael MacFadde

Re: Retirement

[Michael MacFadden]

Yuri,

Being a mostly silent participant at this point.  I would tend to agree with 
you.  I think however, we should provide a “what next” option.  So for example, 
people might be more willing to retire the project if they knew for example we 
could move to github and still allow people to contribute and develop if they 
see fit.

~Michael

On 8/30/16, 11:52 AM, "Yuri Z"  wrote:

After some thought I hate to agree, that at current levels of participation
the only rational choice is to decide to retire as we are just wasting
Apache Foundation resources without any real hope of graduating.
Moreover, there were a few active projects based on Apache Wave that felt
little motivation to contribute back actively. I think this is because they
found little need in Apache Foundation resources, while contributing back
required certain effort to comply with Apache rules.

I think we should hold a retirement vote and either recruit sufficient
number of supporters willing and able actively participate immediately, or
retire.

On Tue, Aug 30, 2016 at 9:13 PM Jonathan Leong  wrote:

> I would hate to see this project retire.
>
> Adam you bring up good points. I can get the ball rolling with the Docker
> image. I'll see what I can get done over the next week or so.
>
>
> -Jonathan Leong
>
>
> On Tue, Aug 30, 2016 at 1:31 PM, Adam John  
wrote:
>
> > I have to weigh in and say that I agree that the bar here was set high
> from
> > several perspectives.
> >
> > I'm currently evaluating what components of this project can be most
> useful
> > for incorporation into 2 separate projects. If either one moves forward
> in
> > the next 6 months, there will be more developers actively involved here.
> >
> > That said, I've watched some of the transition videos from Google folks
> and
> > read a lot of the docs, reviewed code and worked on implementing this
> > project for myself.  It is daunting and would benefit overall from 2
> > significant - imho critical - updates;
> > (1) the Product itself needs real changes - like the concept of bots
> needs
> > pulled out from core terminology and revamped as a more current common
> > concept / ie agents.  There needs to be better organization of the
> Product
> > from concept to contribution.  This is not to diminish the vast 
resources
> > present, only to highlight an improvement area.
> > (2) the Architecture needs serious review and revision to figure out how
> > best to leverage other projects and allow focus on the specific benefits
> > this project enables.  The technology stack overall needs better
> separation
> > at least from a newcomers perspective.
> > As a third factor, and #1 on my list for adoption is rolling docker
> images
> > for the project.  This is essential in my humble opinion to allow new
> > developers to focus on the pieces they feel most equipped to contribute
> > comfortably...
> >
> > I don't know how the major changes I am suggesting get introduced and
> > discussed in much more detail.  I'm hoping that perhaps I lieue of a
> > potentially dismissive email "vote" ... Maybe a virtual conference would
> be
> > of interest?  I would hope that the participants of such a convention
> would
> > be the core of a nascent rebirth.  Yes I am volunteering to help take
> this
> > on if there is interest...
> >
> > Thanks,
> >
> > Adam John
> > (914) 623-8433
> >
> > On Aug 30, 2016 12:43 PM, "Zachary Yaro"  wrote:
> >
> > I am in a similar boat.  I have front-end development skills, but I
> > struggle to fully understand the back-end functionality or begin
> separating
> > the client from the server.
> >
> > Zachary Yaro
> >
> > On Aug 30, 2016 11:51 AM, "Thomas Wrobel"  wrote:
> >
> > > I have tried on 3 separate occasions to understand the server. Its
> > > simply not in my skillset and I don't have the time to learn. I don't
> > > wish to sound arrogant there, theres learning needed for anything of
> > > course. But its too much investment -  I want to apply skills that I
> > > already have. Last time I tried to get into wave development (which
> > > was I admit a few years back) it took me 3 days to even compile the
> > > server. Which is frustrating for someone that just wants to work on a
> > > client.
> > >
> > > So I am certainly not waiting for permission, I am waiting for a
> > > prerequisite  of a server/client split. I understand I can neither
> > > demand or expect such a thing. Developers on a project like this just
> > > have to jump in on what they feel like. Nothing 

Re: Github pull requests discussion

[Michael MacFadden]

I don't know that we have to "move" to git hub pull requests. We can support 
both I guess?

~Michael

> On Apr 24, 2016, at 8:38 AM, Evan Hughes  wrote:
> 
> Regarding #1 see the commits I pushed today.
>> On 25/04/2016 12:58 AM, "Yuri Z"  wrote:
>> 
>> I think we can try it.
>> I see a few cons though:
>> 1. I don't know how to make the asfgit close abandoned pull requests.
>> 2. There's no integration between Jira and github pull requests.
>> 3. There's no link to code review that we can out into commit message, thus
>> providing context for the change. This might be ok for a project that uses
>> Github exclusively,  but for project that uses it only as a mirror - might
>> be tricky. Also, Apache Foundation has no control over GitHub and they can
>> discontinue their service at any second.
>> 
>> The biggest pro for pull requests is that it is easier and can handle
>> binary data - like adding jars/images to source.
>> Anyway, I think I would prefer Review Board, but I won't turn away pull
>> requests too.
>> 
>> On Sun, Apr 24, 2016 at 4:03 PM ๏̯͡๏ Guido Barosio 
>> wrote:
>> 
>>> +1
>>> 
 On Sunday, April 24, 2016, Pablo Ojanguren  wrote:
 
 +1
 
 2016-04-24 6:25 GMT+02:00 Andreas Kotes >:
 
> Hi,
> 
>> On Sun, Apr 24, 2016 at 04:12:52AM +, Evan Hughes wrote:
>> I think we should move to github pull requests as the standardised
>>> way
> for
>> all our repos. ATM we have docs and android client on pull requests
>>> and
> the
>> main repo is through review board. Its easier to get automated
>>> testing
> and
>> is generally easier to submit reviews through pull requests (for me
>> personally).
>> 
>> Would love to hear everyone's opinion and after a couple of days
>>> have a
>> vote.
> 
> github is the way to go, all my current OSS workflows are based
>> around
 it.
> 
>  count
> 
> --
> 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
>>> 
>>> 
>>> --
>>> 
>>> 
>>> [image: --]
>>> 
>>> Guido Barosio
>>> [image: https://]about.me/gbarosio
>>> <
>> https://about.me/gbarosio?promo=email_sig_source=email_sig_medium=email_sig_campaign=external_links
>> 

Re: Should we remove Federation?

[Michael MacFadden]

Yes.  Federation was always part of it at Google.  For example Google had been 
working with companies like SAP and Novell to create things that leveraged with 
/ integrated with Wave from the beginning.  With the idea being that a company 
could use their own wave server with their own employees, and then collaborate 
(like email or chat) with people in other companies if they so desired.

That was part of the rationalization behind the centralized ownership of a Wave 
(that each wave and an authoritative wave sever).  So for example if Company X 
created a Wave, then Company X’s server would own it.  The could choose to 
share (federate) that with other users on other servers, but the server at 
Company X, would still control who it was federating with and would have the 
ownership of the concurrency control (mostly).

This model seems reasonable.  Its just we need to make sure people understand 
what it is, and is not.  But, unless you wanted to change out the OT stack, 
there really is no way to make it peer to peer.  The waves can certainly be 
distributed across many severs (sharded or something).  But at any given time, 
a Wave is controlled by a single server all other servers are subordinate in 
the federation model.

~Michael




On 4/21/16, 12:52 AM, "Evan Hughes" <ehu...@gmail.com> wrote:

>I do see its purpose to allow non-users on this server to communicate with
>waves on another like how macfadden has said its not really decentralised.
>
>Back to bring the attention to the ticket, it has been open since the
>10/4/2016 (dd/mm/). Im not sure if a formal vote is needed but progress
>on the ticket would be nice.
>
>On Thu, 21 Apr 2016 at 17:15 Yuri Z <vega...@gmail.com> wrote:
>
>> I think the Federation was developed as part of the FedOne open source
>> project, but the original Google Wave (sandbox) server could federate with
>> FedOne servers.
>>
>> On Thu, Apr 21, 2016 at 10:13 AM Thomas Wrobel <darkfl...@gmail.com>
>> wrote:
>>
>> > It was always intended to be part of it from what I remember, but I am
>> > not sure how far it got during Googles time.
>> > I think there was some federation, Google<>Pygowave(?) I think was up
>> > and running at one point.
>> > Google wanted Wave as a email replacement, so federation was a
>> > prerequisite.
>> >
>> > As far as modern federation goes, indeed, other then email Google
>> > hasn't got much federation going on. At least that i know of.
>> > But then, basically no companies do.
>> > Its SMTP. And in some cases XMPP. And thats it as far as I know.
>> >
>> >
>> > --
>> > http://lostagain.nl <-- our company site.
>> > http://fanficmaker.com <-- our, really,really, bad story generator.
>> >
>> >
>> > On 21 April 2016 at 07:26, Evan Hughes <ehu...@gmail.com> wrote:
>> > > was federation apart of the original google wave or was integrated
>> during
>> > > the open source transition, because I dont exactly see google in using
>> > > federation other than "google apps for business".
>> > >
>> > > On Tue, 19 Apr 2016 at 14:20 Michael MacFadden <
>> > michael.macfad...@gmail.com>
>> > > wrote:
>> > >
>> > >> One comment I would chime in on here is..
>> > >>
>> > >> Claiming wave’s federation model is decentralized is actually a bit
>> of a
>> > >> stretch.  Every single Wave has an authoritative server.  This is
>> > typically
>> > >> the server on which the Wave was created.  All of the other servers
>> > >> participating in the federation have to send all deltas back to the
>> > >> authoritative server, and then those operations are processed and set
>> > out
>> > >> to other systems.
>> > >>
>> > >> In point of fact, if person A creates a Wave on server 1.  Then
>> person B
>> > >> and C join from server 2.  When person B types, the operation has to
>> go
>> > >> from B’s client to Server 2, then to Server 1, then back to Server 2,
>> > then
>> > >> to C’s client.  So even though B and C are on the same server, their
>> > >> collaboration goes through Server 1.
>> > >>
>> > >> Wave is only decentralized in the fact that 1) users can be locally
>> > >> authenticated to servers and a chain of trust is set up between them
>> as
>> > to
>> > >> the identity of users, and 2) that waves can be created anywh

Re: Should we remove Federation? Wave as XEP/XMMP Extension

[Michael MacFadden]

I don’t want to put words in anyones mouth, but I recall some one from google 
once telling me that the main reason for XMPP was that google already had a 
significant XMPP infrastructure because of things like gtalk.  And that it had 
already worked out a federation and authentication  trust model.  No one ever 
said it was the best thing to do, but at the time it was the right thing to do. 
 That may or may not be valid so many years later, and doing it from scratch.




On 4/19/16, 4:17 AM, "Pablo Ojanguren" <pablo...@gmail.com> wrote:

>I guess that XMPP manages federation aspects like identity and server
>discovery that we don't have out-of-the-box with just things like
>protobuffers.
>To say just "transport" is a simplification, probably is better to say
>"federated transport" or "federated communication infrastructure"
>
>2016-04-19 12:39 GMT+02:00 Dave Ball <w...@glark.co.uk>:
>
>> I'm not sure that 'XMPP as a transport' is too much of a problem, so much
>> as the current implementation is quite complex.
>>
>> Currently wave requires an external XMPP server, and plugs into that as an
>> extension.  This can be scalable but our implementation and configuration
>> could be simplified by e.g. embedding a simple XMPP server.
>>
>> Wave doesn't need a lot of the 'instant messaging' functionality provided
>> by full xmpp servers - iirc our users, buddy lists & message data are all
>> wave specific on top of xmpp.
>>
>> If we _are_ considering replacing the transport it might be worth looking
>> at something like ProtoBuffers directly on tcp, rather than using an
>> existing instant messaging framework?  XMPP is fine, but the "instant
>> messaging" functionality doesn't really give us anything?
>>
>> My preference would be for federation that works out-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 rate that a OT system
>>> like Wave produce.
>>> In that sense is also interesting projects like IPFS <https://ipfs.io/>
>>>
>>> In addition, I am still think that the current Wave model federation is
>>> good (even it replicates data), the issues is the transport, so I suggest
>>> to try Matrix.org as replacement of XMPP. I will look into it in following
>>> weeks, and I am trying to get someone in SwellRT's GSoC to work on that
>>> during summer
>>>
>>> 2016-04-19 11:35 GMT+02:00 Yuri Z <vega...@gmail.com>:
>>>
>>> I was thinking about Federation via persistence level. In particular when
>>>> all the content persisted into database, but the database is
>>>> decentralized
>>>> (like bitcoin blockchain). The content though is encrypted. Each wave is
>>>> encrypted with a new key. Whenever a participant is added to the wave -
>>>> whoever adds him also adds a new record into this user data wavelet with
>>>> the wave private key that is encrypted with the user's public key. This
>>>> way
>>>> only the new user gets access the the wave private key.
>>>> I.e. all the content is public, but encrypted. Only those that control a
>>>> certain key can decrypt the message and add new content.
>>>> So, this architecture follows the bitcoin model - anyone can host his own
>>>> wave blockchain (like running his own wallet) or use a web wallet - i.e.
>>>> wave client hosted by someone else.
>>>>
>>>> On Tue, Apr 19, 2016 at 12:24 PM Andreas Kotes <co...@flatline.de>
>>>> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> On Mon, Apr 18, 2016 at 09:20:43PM -0700, Michael MacFadden wrote:
>>>>>
>>>>>> However, with respect to a particular wave, the federation model is
>>>>>> very much centralized.  It is not decentralized in the same way that
>>>>>> XMPP and SMTP are.  This is actually a function of how the Wave OT
>>>>>> algorithm works and not an issue with the transport or XMPP.
>>>>>>
>>>>> I'd even say that's the correct way to do it. One server should feel
>>>>> responsible for safeguarding the document regarding security and
>>>>> availability.
>>>>>
>>>>> If a document is decentralized only, versions can diverge and copies
>>>>> might go offline or disappear altogether, with the possibility of no
>>>>> copy remaining.
>>>>>
>>>>> The transport as such shouldn't matter too much - although if we stay
>>>>> in the Java/XML realm, XMPP sounds like a good fit, especially as (via
>>>>> Jabber) it has a lot of established infrastructure.
>>>>>
>>>>> Maybe Apache Wave would even make a good set of (official) XMPP
>>>>>
>>>> extensions?
>>>>
>>>>> Cheers,
>>>>>
>>>>> count
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>

Re: Should we remove Federation? Wave as XEP/XMMP Extension

[Michael MacFadden]

There was actually some research on this out of a French group.  I can try to 
find the reference.




On 4/19/16, 2:35 AM, "Yuri Z" <vega...@gmail.com> wrote:

>I was thinking about Federation via persistence level. In particular when
>all the content persisted into database, but the database is decentralized
>(like bitcoin blockchain). The content though is encrypted. Each wave is
>encrypted with a new key. Whenever a participant is added to the wave -
>whoever adds him also adds a new record into this user data wavelet with
>the wave private key that is encrypted with the user's public key. This way
>only the new user gets access the the wave private key.
>I.e. all the content is public, but encrypted. Only those that control a
>certain key can decrypt the message and add new content.
>So, this architecture follows the bitcoin model - anyone can host his own
>wave blockchain (like running his own wallet) or use a web wallet - i.e.
>wave client hosted by someone else.
>
>On Tue, Apr 19, 2016 at 12:24 PM Andreas Kotes <co...@flatline.de> wrote:
>
>> Hi,
>>
>> On Mon, Apr 18, 2016 at 09:20:43PM -0700, Michael MacFadden wrote:
>> > However, with respect to a particular wave, the federation model is
>> > very much centralized.  It is not decentralized in the same way that
>> > XMPP and SMTP are.  This is actually a function of how the Wave OT
>> > algorithm works and not an issue with the transport or XMPP.
>>
>> I'd even say that's the correct way to do it. One server should feel
>> responsible for safeguarding the document regarding security and
>> availability.
>>
>> If a document is decentralized only, versions can diverge and copies
>> might go offline or disappear altogether, with the possibility of no
>> copy remaining.
>>
>> The transport as such shouldn't matter too much - although if we stay
>> in the Java/XML realm, XMPP sounds like a good fit, especially as (via
>> Jabber) it has a lot of established infrastructure.
>>
>> Maybe Apache Wave would even make a good set of (official) XMPP extensions?
>>
>> Cheers,
>>
>>count
>>
>> --
>> 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
>>

Re: Should we remove Federation?

[Michael MacFadden]

One comment I would chime in on here is..

Claiming wave’s federation model is decentralized is actually a bit of a 
stretch.  Every single Wave has an authoritative server.  This is typically the 
server on which the Wave was created.  All of the other servers participating 
in the federation have to send all deltas back to the authoritative server, and 
then those operations are processed and set out to other systems.

In point of fact, if person A creates a Wave on server 1.  Then person B and C 
join from server 2.  When person B types, the operation has to go from B’s 
client to Server 2, then to Server 1, then back to Server 2, then to C’s 
client.  So even though B and C are on the same server, their collaboration 
goes through Server 1.

Wave is only decentralized in the fact that 1) users can be locally 
authenticated to servers and a chain of trust is set up between them as to the 
identity of users, and 2) that waves can be created anywhere so the 
authoritative server for each wave could be different.

However, with respect to a particular wave, the federation model is very much 
centralized.  It is not decentralized in the same way that XMPP and SMTP are.  
This is actually a function of how the Wave OT algorithm works and not an issue 
with the transport or XMPP.

~Michael



On 4/10/16, 4:14 AM, "Pablo Ojanguren" <pablo...@gmail.com> wrote:

>I fully agree, federation is mandatory, and it's what makes wave unique
>from centralized technologies.
>
>I wonder what is the actual issue with federation... is it XMPP? is it the
>implementation itself? is it the wave protocol design?
>
>
>2016-04-09 23:02 GMT+02:00 Yuri Z <vega...@gmail.com>:
>
>> I am not sure we know how to do it right anyways.
>>
>> On Sat, Apr 9, 2016 at 11:53 PM Michael MacFadden <
>> michael.macfad...@gmail.com> wrote:
>>
>> > I agree,  I don’t think any one was talking about removing federation as
>> a
>> > goal.
>> >
>> >
>> >
>> >
>> > On 4/9/16, 6:34 AM, "Thomas Wrobel" <darkfl...@gmail.com> wrote:
>> >
>> > >Oh, if its only the current implementation, sure if its not got value.
>> > >Being merely a onlooker its been a long time since I have looked at
>> > >the codebase - but would removing even a broken implementation cause
>> > >any issues as regards to putting a new implementation in in the
>> > >future? That is, does it serve a purpose even as a ''placeholder'' to
>> > >prevent other aspects of the code being made in a way as to make
>> > >federation awkward later?
>> > >
>> > >
>> > >--
>> > >http://lostagain.nl <-- our company site.
>> > >http://fanficmaker.com <-- our, really,really, bad story generator.
>> > >
>> > >
>> > >On 8 April 2016 at 00:10, Evan Hughes <ehu...@gmail.com> wrote:
>> > >> Removing the current implementation is fine, I see no problems with
>> > that,
>> > >> aslong as theres enough documents to be able to recreate it from spec.
>> > >> On 08/04/2016 2:22 AM, "Yuri Z" <vega...@gmail.com> wrote:
>> > >>
>> > >>> I cannot agree more, Wave is about federation. But, the current
>> > >>> implementation is broken, hard to fix and never worked fine. We need
>> to
>> > >>> think about better implementation. And there's no point to keep
>> current
>> > >>> broken implementation that can't work.
>> > >>>
>> > >>> On Thu, Apr 7, 2016 at 6:55 PM Dave Ball <w...@glark.co.uk> wrote:
>> > >>>
>> > >>> > 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 because I didn't want the net turning into
>> > "facebook
>> > >>> > > protocols" and "google protocols" etc.  We need new emails.
>> > Protocols
>> > >>> > > that allow people on different servers to communicate, not
>> > protocols
>> > >>> > > trying to get everyone on the same companies server.
>> > >>> > > I still fear a fut

Re: Should we remove Federation?

[Michael MacFadden]

I agree,  I don’t think any one was talking about removing federation as a goal.




On 4/9/16, 6:34 AM, "Thomas Wrobel"  wrote:

>Oh, if its only the current implementation, sure if its not got value.
>Being merely a onlooker its been a long time since I have looked at
>the codebase - but would removing even a broken implementation cause
>any issues as regards to putting a new implementation in in the
>future? That is, does it serve a purpose even as a ''placeholder'' to
>prevent other aspects of the code being made in a way as to make
>federation awkward later?
>
>
>--
>http://lostagain.nl <-- our company site.
>http://fanficmaker.com <-- our, really,really, bad story generator.
>
>
>On 8 April 2016 at 00:10, Evan Hughes  wrote:
>> Removing the current implementation is fine, I see no problems with that,
>> aslong as theres enough documents to be able to recreate it from spec.
>> On 08/04/2016 2:22 AM, "Yuri Z"  wrote:
>>
>>> I cannot agree more, Wave is about federation. But, the current
>>> implementation is broken, hard to fix and never worked fine. We need to
>>> think about better implementation. And there's no point to keep current
>>> broken implementation that can't work.
>>>
>>> On Thu, Apr 7, 2016 at 6:55 PM Dave Ball  wrote:
>>>
>>> > 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 because I didn't want the net turning into "facebook
>>> > > protocols" and "google protocols" etc.  We need new emails. Protocols
>>> > > that allow people on different servers to communicate, not protocols
>>> > > trying to get everyone on the same companies server.
>>> > > I still fear a future of incompatibility. Of people having to be on
>>> > > server X because their friends are all on server X (and thus server X
>>> > > has no incentive to ever get better). Email is getting increasingly
>>> > > dated, and there's not much else federated out there even today. As
>>> > > the web grows into real-space applications, there will be probably
>>> > > even greater need for open communications standards.
>>> > > While the comparison of email interface wise might have harmed wave
>>> > > somewhat from a user expectation standpoint, I do think the same needs
>>> > > are there - a new federated, open, protocol to deal with today's web.
>>> > > - sigh -
>>> > > --
>>> > > http://lostagain.nl <-- our company site.
>>> > > http://fanficmaker.com <-- our, really,really, bad story generator.
>>> > >
>>> > >
>>> > > On 7 April 2016 at 17:25, Yuri Z  wrote:
>>> > >> Hi
>>> > >> Currently the federation is broken and requires a significant effort
>>> to
>>> > >> fix. Moreover, it never worked perfectly and always was a kind of
>>> Proof
>>> > Of
>>> > >> Concept version. I doubt we can improve the current implementation to
>>> be
>>> > >> something stable.
>>> > >> Therefore I suggest to remove from Wave source all code and
>>> dependencies
>>> > >> related to Federation.
>>> > >> Thoughts?
>>> >
>>> >
>>>

Re: A Wavy Future

[Michael MacFadden]

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 the editor.  OT will take care of making 
sure operations are transformed into the correct state space such that the end 
result can simply be calling an API on the editor that says (insert text here).

~Michael



On 3/15/16, 6:29 PM, "Evan Hughes" <ehu...@gmail.com> wrote:

>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
>

Re: Speed issues of wiab resolved and open sourced on github

[Michael MacFadden]

Cool. Is there a current demo of this running some where?

~Michael




On 3/16/16, 5:01 AM, "Yuri Z"  wrote:

>Hi Kirill
>Great news, thanks!
>I think those were the main issues with Apache Wave. Hopefully your
>contributions will allow us to fix those issues and make Apache Wave faster
>and more stable.
>
>On Wed, Mar 16, 2016 at 1:59 PM Kirill Kostyuchenko 
>wrote:
>
>> Hello developers!
>>
>> We released our features to github repository
>> https://github.com/jorkey/Wiab.pro
>>
>> The key features is indexed delta storage and new rendering mechanism.
>>

Re: A Wavy Future

[Michael MacFadden]

ot;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 t

Re: A Wavy Future

[Michael MacFadden]

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> 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>
> 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> 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>
>> 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>
>>>> 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
>> 

Re: A Wavy Future

[Michael MacFadden]

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 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 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 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
>> 

Re: A Wavy Future

[Michael MacFadden]

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
> 
>> On Fri, 11 Mar 2016 at 19:48 Evan Hughes  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 
>> 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
>> 

Re: A Wavy Future

[Michael MacFadden]

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, "Michael MacFadden" <michael.macfad...@gmail.com> wrote:

>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 thing I would say is that the Client’s data model / rendering approach is 
>fairly sophisticated in two regards.  First building any sort of rich text 
>editor in the browser is some what difficult.  I am not sure that undertaking 
>that particular effort, GWT or otherwise is going to be easy.  The rest of the 
>UI could be easily redone quickly, but the editor would take months and months 
>to do from scratch.  I think we would want to consider if we should be looking 
>at using an existing editor that is out there.  
>
>The other area where the UI is complex is in the performance aspect of it.  
>The wave UI is designed to load a ton of “blips”.  The content over time could 
>become very, very long.  There was some measure of thought put into the 
>current system to make rendering and eventing very fast to handle large 
>conversations.
>
>Just a few thoughts.
>
>~Michael
>
>
>
>
>On 3/10/16, 4:34 PM, "Thomas Wrobel" <darkfl...@gmail.com> wrote:
>
>>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 <wisebald...@apache.org> 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 on any of the changes.
>>>
>>> Sincerely,
>>> Evan Hughes
>

Re: A Wavy Future

[Michael MacFadden]

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 thing I would say is that the Client’s data model / rendering approach is 
fairly sophisticated in two regards.  First building any sort of rich text 
editor in the browser is some what difficult.  I am not sure that undertaking 
that particular effort, GWT or otherwise is going to be easy.  The rest of the 
UI could be easily redone quickly, but the editor would take months and months 
to do from scratch.  I think we would want to consider if we should be looking 
at using an existing editor that is out there.  

The other area where the UI is complex is in the performance aspect of it.  The 
wave UI is designed to load a ton of “blips”.  The content over time could 
become very, very long.  There was some measure of thought put into the current 
system to make rendering and eventing very fast to handle large conversations.

Just a few thoughts.

~Michael




On 3/10/16, 4:34 PM, "Thomas Wrobel"  wrote:

>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 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 on any of the changes.
>>
>> Sincerely,
>> Evan Hughes

Re: Web Designers

[Michael MacFadden]

I agree.  I did the initial design of the site we have many years ago, and we 
really haven’t done much with it since than.  Should we perhaps put an 
“advertisement” on the current web site letting folks know we are looking for 
help with a new design?  If so, I could add that to our current site.

~Michael




On 1/30/16, 2:10 AM, "Evan Hughes"  wrote:

>Hello all,
>
>We need a new website for our homepage and a new docs template design,
>surely we have a few designers here that would be willing to spend some
>time designing a new website. Just to be clear I'm not asking for people to
>also implement it but we need a designer.
>
>The new design should also use the new Apache logo if people have not
>already seen it.
>
>http://www.apache.org/img/asf_logo.png
>
>If you would like to implement it after a design is made then go for it,
>but first things first, designers.
>
>~ Evan

Re: [RESULT][VOTE] Wave 0.4.0-rc10

[Michael MacFadden]

Is there anything we can do to help with that?




On 11/14/15, 6:07 AM, "Ali Lown"  wrote:

>I am trying to get enough votes from IPMC, we need 3 but only have 2
>currently (Justin, Christian).
>
>Ali
>
>On 14 November 2015 at 00:25, Evan Hughes  wrote:
>> Is the release still stuck due to the issue the general member is having?
>> On 06/11/2015 4:13 AM, "Upayavira"  wrote:
>>
>>> Ahh, got it. What you meant was:
>>>   6 committer votes
>>>   1 mentor vote
>>>   4 non-binding
>>>
>>> I took it to mean 6 votes total, of which 1 mentor and 4 non-bonding.
>>>
>>> Clarity shines forth, thank you.
>>>
>>> Are you now in a position to forward this to general@incubator?
>>>
>>> Thx
>>>
>>> On Thu, Nov 5, 2015, at 05:10 PM, Ali Lown wrote:
>>> > Upayavira,
>>> >
>>> > Am I overlooking something?
>>> >
>>> > I definitely wrote 6 committer votes (+1 mentor vote) in the email
>>> > dated 3rd November.
>>> >
>>> >
>>> https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201511.mbox/%3CCABRGrVenajwQPBw98Zy99UqrMNNQMJ-X5tGcWWAMR3xNX%2Bnu7w%40mail.gmail.com%3E
>>> >
>>> > Ali
>>> >
>>> > On 3 November 2015 at 19:46, Upayavira  wrote:
>>> > > Congrats Ali, and good luck with your future plans!
>>> > >
>>> > > Can I ask you to check those tallies? I'm sure there are more
>>> > > committer/PPMC member votes than two.
>>> > >
>>> > > Upayavira
>>> > >
>>> > > On Tue, Nov 3, 2015, at 03:22 PM, Ali Lown wrote:
>>> > >> Hi all,
>>> > >>
>>> > >> Thanks for taking part in verifying this release candidate, it is
>>> > >> great to finally be able to take a potential release to the others in
>>> > >> the incubator!
>>> > >> (I apologize for not following up sooner, I have finally graduated
>>> > >> from Uni, so am now sorting out what comes next...)
>>> > >>
>>> > >> These results supersede the email I sent dated 18th October, with the
>>> > >> results now looking like:
>>> > >>
>>> > >> +1: 6 (+1 mentor, +4 non-binding)
>>> > >> +0: 0
>>> > >> -0:  0
>>> > >> -1:  0
>>> > >>
>>> > >> Ali
>>> > >>
>>> > >> On 18 October 2015 at 02:48, Ali Lown  wrote:
>>> > >> > Hi all,
>>> > >> >
>>> > >> > Thanks to Yuri and Jeremy for downloading and trying out this RC.
>>> > >> >
>>> > >> > Well, I set a "deadline" around the 17th October which has now well
>>> > >> > and truly passed.
>>> > >> >
>>> > >> > My vote on the matter was a +1 (though I realize that I failed to
>>> put
>>> > >> > this in my original email, so you are allowed to ignore this for
>>> > >> > failing to meet my own deadline).
>>> > >> >
>>> > >> > The result looks something like (including mine):
>>> > >> > +1: 3 (2 binding)
>>> > >> > +0: 0
>>> > >> > -0: 0
>>> > >> > -1: 0
>>> > >> >
>>> > >> > Unfortunately we have had insufficient votes to meet the release
>>> > >> > requirement (minimum of 3 +1 binding votes, more + than -) [0].
>>> > >> > Binding votes as decided by people in [1].
>>> > >> >
>>> > >> > @Yuri/Jeremy: How do you feel now about us moving away from Apache,
>>> as
>>> > >> > this vote does seem to suggest that there is not enough interest
>>> from
>>> > >> > the currently defined committers to maintain this project here.
>>> > >> >
>>> > >> > I am not really sure why none of the other committers responded at
>>> all
>>> > >> > to the vote...
>>> > >> >
>>> > >> > Ali
>>> > >> >
>>> > >> > [0]:
>>> https://www.apache.org/foundation/voting.html#votes-on-code-modification
>>> > >> > [1]: https://people.apache.org/committers-by-project.html#wave
>>> > >> >
>>> > >> > On 14 October 2015 at 17:27, Jérémy Naegel 
>>> wrote:
>>> > >> >> +1
>>> > >> >>
>>> > >> >> +Jérémy Naegel >> >
>>> > >> >> Public Information Officer
>>> > >> >>
>>> > >> >> On Mon, Oct 12, 2015 at 9:24 PM, Yuri Z  wrote:
>>> > >> >>
>>> > >> >>> +1
>>> > >> >>> I did the following:
>>> > >> >>> - Checked signatures
>>> > >> >>> - Opened the binary and verified it works.
>>> > >> >>> - Opened the source and verified that it can be built and works.
>>> > >> >>> - Reviewed the changes for the rc 10.
>>> > >> >>>
>>> > >> >>> Ali - Thanks for making this RC!
>>> > >> >>>
>>> > >> >>> On Sat, Oct 10, 2015 at 9:59 AM Ali Lown  wrote:
>>> > >> >>>
>>> > >> >>> > Hi all,
>>> > >> >>> >
>>> > >> >>> > RC10 is now available for review.
>>> > >> >>> > Artefacts can be found here:
>>> > >> >>> > https://people.apache.org/~al/wave_rc/0.4-rc10/
>>> > >> >>> > (Remember checksums are from 'gpg --print-md SHA512 $f >
>>> $f.sha')
>>> > >> >>> >
>>> > >> >>> > I have included both source and binary artefacts for
>>> convenience.
>>> > >> >>> >
>>> > >> >>> > The release version (if successful) will be 0.4.0-incubating
>>> > >> >>> >
>>> > >> >>> > This is taken from the branch 0.4.0-rc10 of the incubator-wave
>>> > >> >>> repository.
>>> > >> >>> >

Re: [VOTE] Wave 0.4.0-rc10

[Michael MacFadden]

It would seem so.




On 10/27/15, 7:34 PM, "Evan Hughes" <ehu...@gmail.com> wrote:

>I believe we have enough votes if I'm not mistaken?
>
>On 26 October 2015 at 11:53, Rahul Tokase <rahultok...@gmail.com> wrote:
>
>> +1
>>
>> On 26 Oct 2015 00:53, "Christian Grobmeier" <grobme...@apache.org> wrote:
>> >
>> > Hey folks,
>> >
>> > I checked but didn't find anything. +1 from me.
>> >
>> > I checked on legals of course.
>> >
>> > Cheers
>> >
>> > On Sat, Oct 24, 2015, at 01:11, Evan Hughes wrote:
>> > > +1
>> > > On 24/10/2015 4:17 AM, "Ben Hegarty" <heg...@gmail.com> wrote:
>> > >
>> > > > +1
>> > > >
>> > > > On Fri, Oct 23, 2015 at 5:45 AM, Michael MacFadden <
>> > > > michael.macfad...@gmail.com> wrote:
>> > > >
>> > > > > +1
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On 10/22/15, 2:13 PM, "Alex North" <a...@alexn.id.au> wrote:
>> > > > >
>> > > > > >+1
>> > > > > >
>> > > > > >On Thu, 22 Oct 2015 at 22:08 Vicente J. Ruiz Jurado <
>> > > > v...@ourproject.org>
>> > > > > >wrote:
>> > > > > >
>> > > > > >> El 10/10/15 a las 08:58, Ali Lown escribió:
>> > > > > >> > Hi all,
>> > > > > >> >
>> > > > > >> > RC10 is now available for review.
>> > > > > >> > Artefacts can be found here:
>> > > > > >> > https://people.apache.org/~al/wave_rc/0.4-rc10/
>> > > > > >> > (Remember checksums are from 'gpg --print-md SHA512 $f >
>> $f.sha')
>> > > > > >> >
>> > > > > >> > I have included both source and binary artefacts for
>> convenience.
>> > > > > >> >
>> > > > > >> > The release version (if successful) will be 0.4.0-incubating
>> > > > > >> >
>> > > > > >> > This is taken from the branch 0.4.0-rc10 of the incubator-wave
>> > > > > >> repository.
>> > > > > >> >
>> > > > > >> > Notable changes since earlier initial release attempts
>> include:
>> > > > > >> > - Use of typesafe config
>> > > > > >> > - Bumped versions of Jetty, GWT, etc.
>> > > > > >> > - Assorted tweaks to build system
>> > > > > >> >
>> > > > > >> > A summary of useful information can be found in RELEASE-NOTES,
>> and a
>> > > > > >> > list of changes in CHANGES in the source artefacts.
>> > > > > >> >
>> > > > > >> > Action Required:
>> > > > > >> > Please go and test these packages (most importantly the source
>> ones)
>> > > > > >> > for any outstanding legal problems, or any runtime problems in
>> a
>> > > > > >> > 'standard' configuration.
>> > > > > >> >
>> > > > > >> > We are not looking for a perfect first release, as there is
>> plenty
>> > > > of
>> > > > > >> > time to fix outstanding bugs in future releases, but we do
>> want to
>> > > > get
>> > > > > >> > 0.4 out soon (at long last).
>> > > > > >> >
>> > > > > >> > This vote will close around  GMT 17th October 2015.
>> > > > > >> >
>> > > > > >> > [ ] +1 Release it!
>> > > > > >> > [ ] +0 Ok, but...
>> > > > > >> > [ ] -0  Ok, but you really should fix...
>> > > > > >> > [ ] -1 Definitely do not release this because...
>> > > > > >> >
>> > > > > >> > Thanks,
>> > > > > >> > Ali
>> > > > > >> >
>> > > > > >>
>> > > > > >> If is not too late:
>> > > > > >>
>> > > > > >> +1
>> > > > > >>
>> > > > > >> Thanks Ali,
>> > > > > >>
>> > > > > >> Vicente
>> > > > > >>
>> > > > > >> PS: Tested the binaries, and sources (compiling, etc),
>> registration,
>> > > > > >> editing, etc. About legal, etc: "ant audit-licenses" looks good
>> to my
>> > > > > >> (only a warning about a atmosphere minified version that is
>> Apache
>> > > > > >> licensed).
>> > > > > >>
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Regards
>> > > > Ben
>> > > >
>>

Re: [RESULT][VOTE] Wave 0.4.0-rc10

[Michael MacFadden]

Ok,

I am revising the legal perspective today.




On 10/20/15, 6:40 PM, "Upayavira" <u...@odoko.co.uk> wrote:

>As far as I'm concerned, you can still vote on the existing thread.
>Please vote from a legal perspective rather than a technical one.
>
>The timeframe is set to ensure people have the ability to vote - it
>isn't a requirement that it completes within a specific timeframe.
>
>thx.
>
>Upayavira
>
>On Mon, Oct 19, 2015, at 09:39 PM, Michael MacFadden wrote:
>> All,
>> 
>> I still find the Wave project quite interesting and am more than happy to
>> help.  I just haven’t really felt the pull of the community.  If I
>> thought there we something specific I could do to help I would be more
>> than happy.  I would like to see the release finally happen.  Even if we
>> eventually move away it would be nice to have completed this process once
>> during the life of the project.
>> 
>> If there is another vote I will participate.  I will review the process
>> and functional status and provide a vote.
>> 
>> So you can count me in.
>> 
>> ~Michael
>> 
>> 
>> 
>> 
>> On 10/18/15, 4:56 AM, "Upayavira" <u...@odoko.co.uk> wrote:
>> 
>> >Non-binding votes have a different value. If we had insufficient
>> >committer/PPMC votes but loads of quality (I.e not drive by) non-binding
>> >votes, it would suggest we have a different problem, and could look how
>> >to addresss that.
>> >
>> >Upayavira
>> >
>> >On Sat, Oct 17, 2015, at 09:33 PM, Zachary Yaro wrote:
>> >> I would have cast a vote, but I read non-binding votes were discouraged.
>> >> To clarify, what are the criteria for being able to cast a binding vote
>> >> for
>> >> this project?
>> >> 
>> >> Zachary Yaro
>> >> 
>> >> On 17 October 2015 at 21:48, Ali Lown <a...@lown.me.uk> wrote:
>> >> 
>> >> > Hi all,
>> >> >
>> >> > Thanks to Yuri and Jeremy for downloading and trying out this RC.
>> >> >
>> >> > Well, I set a "deadline" around the 17th October which has now well
>> >> > and truly passed.
>> >> >
>> >> > My vote on the matter was a +1 (though I realize that I failed to put
>> >> > this in my original email, so you are allowed to ignore this for
>> >> > failing to meet my own deadline).
>> >> >
>> >> > The result looks something like (including mine):
>> >> > +1: 3 (2 binding)
>> >> > +0: 0
>> >> > -0: 0
>> >> > -1: 0
>> >> >
>> >> > Unfortunately we have had insufficient votes to meet the release
>> >> > requirement (minimum of 3 +1 binding votes, more + than -) [0].
>> >> > Binding votes as decided by people in [1].
>> >> >
>> >> > @Yuri/Jeremy: How do you feel now about us moving away from Apache, as
>> >> > this vote does seem to suggest that there is not enough interest from
>> >> > the currently defined committers to maintain this project here.
>> >> >
>> >> > I am not really sure why none of the other committers responded at all
>> >> > to the vote...
>> >> >
>> >> > Ali
>> >> >
>> >> > [0]:
>> >> > https://www.apache.org/foundation/voting.html#votes-on-code-modification
>> >> > [1]: https://people.apache.org/committers-by-project.html#wave
>> >> >
>> >> > On 14 October 2015 at 17:27, Jérémy Naegel <jeremy@gmail.com> wrote:
>> >> > > +1
>> >> > >
>> >> > > +Jérémy Naegel <http://google.com/+JérémyNaegel
>> >> > <http://google.com/+J%C3%A9r%C3%A9myNaegel>>
>> >> > > Public Information Officer
>> >> > >
>> >> > > On Mon, Oct 12, 2015 at 9:24 PM, Yuri Z <vega...@gmail.com> wrote:
>> >> > >
>> >> > >> +1
>> >> > >> I did the following:
>> >> > >> - Checked signatures
>> >> > >> - Opened the binary and verified it works.
>> >> > >> - Opened the source and verified that it can be built and works.
>> >> > >> - Reviewed the changes for the rc 10.
>> >> > >>
>> >> > >> Ali - Thanks for making this RC!
>> >> &

Re: [RESULT][VOTE] Wave 0.4.0-rc10

[Michael MacFadden]

All,

I still find the Wave project quite interesting and am more than happy to help. 
 I just haven’t really felt the pull of the community.  If I thought there we 
something specific I could do to help I would be more than happy.  I would like 
to see the release finally happen.  Even if we eventually move away it would be 
nice to have completed this process once during the life of the project.

If there is another vote I will participate.  I will review the process and 
functional status and provide a vote.

So you can count me in.

~Michael




On 10/18/15, 4:56 AM, "Upayavira"  wrote:

>Non-binding votes have a different value. If we had insufficient
>committer/PPMC votes but loads of quality (I.e not drive by) non-binding
>votes, it would suggest we have a different problem, and could look how
>to addresss that.
>
>Upayavira
>
>On Sat, Oct 17, 2015, at 09:33 PM, Zachary Yaro wrote:
>> I would have cast a vote, but I read non-binding votes were discouraged.
>> To clarify, what are the criteria for being able to cast a binding vote
>> for
>> this project?
>> 
>> Zachary Yaro
>> 
>> On 17 October 2015 at 21:48, Ali Lown  wrote:
>> 
>> > Hi all,
>> >
>> > Thanks to Yuri and Jeremy for downloading and trying out this RC.
>> >
>> > Well, I set a "deadline" around the 17th October which has now well
>> > and truly passed.
>> >
>> > My vote on the matter was a +1 (though I realize that I failed to put
>> > this in my original email, so you are allowed to ignore this for
>> > failing to meet my own deadline).
>> >
>> > The result looks something like (including mine):
>> > +1: 3 (2 binding)
>> > +0: 0
>> > -0: 0
>> > -1: 0
>> >
>> > Unfortunately we have had insufficient votes to meet the release
>> > requirement (minimum of 3 +1 binding votes, more + than -) [0].
>> > Binding votes as decided by people in [1].
>> >
>> > @Yuri/Jeremy: How do you feel now about us moving away from Apache, as
>> > this vote does seem to suggest that there is not enough interest from
>> > the currently defined committers to maintain this project here.
>> >
>> > I am not really sure why none of the other committers responded at all
>> > to the vote...
>> >
>> > Ali
>> >
>> > [0]:
>> > https://www.apache.org/foundation/voting.html#votes-on-code-modification
>> > [1]: https://people.apache.org/committers-by-project.html#wave
>> >
>> > On 14 October 2015 at 17:27, Jérémy Naegel  wrote:
>> > > +1
>> > >
>> > > +Jérémy Naegel > > >
>> > > Public Information Officer
>> > >
>> > > On Mon, Oct 12, 2015 at 9:24 PM, Yuri Z  wrote:
>> > >
>> > >> +1
>> > >> I did the following:
>> > >> - Checked signatures
>> > >> - Opened the binary and verified it works.
>> > >> - Opened the source and verified that it can be built and works.
>> > >> - Reviewed the changes for the rc 10.
>> > >>
>> > >> Ali - Thanks for making this RC!
>> > >>
>> > >> On Sat, Oct 10, 2015 at 9:59 AM Ali Lown  wrote:
>> > >>
>> > >> > Hi all,
>> > >> >
>> > >> > RC10 is now available for review.
>> > >> > Artefacts can be found here:
>> > >> > https://people.apache.org/~al/wave_rc/0.4-rc10/
>> > >> > (Remember checksums are from 'gpg --print-md SHA512 $f > $f.sha')
>> > >> >
>> > >> > I have included both source and binary artefacts for convenience.
>> > >> >
>> > >> > The release version (if successful) will be 0.4.0-incubating
>> > >> >
>> > >> > This is taken from the branch 0.4.0-rc10 of the incubator-wave
>> > >> repository.
>> > >> >
>> > >> > Notable changes since earlier initial release attempts include:
>> > >> > - Use of typesafe config
>> > >> > - Bumped versions of Jetty, GWT, etc.
>> > >> > - Assorted tweaks to build system
>> > >> >
>> > >> > A summary of useful information can be found in RELEASE-NOTES, and a
>> > >> > list of changes in CHANGES in the source artefacts.
>> > >> >
>> > >> > Action Required:
>> > >> > Please go and test these packages (most importantly the source ones)
>> > >> > for any outstanding legal problems, or any runtime problems in a
>> > >> > 'standard' configuration.
>> > >> >
>> > >> > We are not looking for a perfect first release, as there is plenty of
>> > >> > time to fix outstanding bugs in future releases, but we do want to get
>> > >> > 0.4 out soon (at long last).
>> > >> >
>> > >> > This vote will close around  GMT 17th October 2015.
>> > >> >
>> > >> > [ ] +1 Release it!
>> > >> > [ ] +0 Ok, but...
>> > >> > [ ] -0  Ok, but you really should fix...
>> > >> > [ ] -1 Definitely do not release this because...
>> > >> >
>> > >> > Thanks,
>> > >> > Ali
>> > >> >
>> > >>
>> >

Re: [VOTE] Wave Release Candidate 9

[Michael MacFadden]

+1

~Michael

 On May 30, 2015, at 3:01 AM, Yuri Z vega...@gmail.com wrote:
 
 Ok, should we then proceed with release while adding a notice that
 federation is broken atm?
 
 On Sat, May 30, 2015 at 11:23 AM Upayavira u...@odoko.co.uk wrote:
 
 remember that the intent of this release is to show that we know how to
 do it, not to make it perfect.
 
 A release with some bugs, given the stage of development of Wave, is
 potentially a *good* thing rather than a bad one, as it may provide
 newcomers with the incentive to help fix those bugs.
 
 Let's get a legally correct release out now, and then aim to follow it
 with another that has more bugs fixed.
 
 Upayavira
 
 On Fri, May 29, 2015, at 09:36 PM, Yuri Z wrote:
 Well, actually it looks like we have an issue with federation...
 
 On Fri, May 29, 2015 at 11:35 PM Upayavira u...@odoko.co.uk wrote:
 
 What I'm waiting to hear is here's a release that we've all voted on
 and think is ready, which I will then review and (hopefully) pass onto
 the incubator PMC for further review.
 
 Upayavira
 
 On Fri, May 29, 2015, at 07:59 AM, Ben Hegarty wrote:
 A massive +1, that would be a massive help as I know that I spend
 ages
 figuring that out! :)
 
 Regards
 Ben
 
 On 29 May 2015, at 03:15, Evan Hughes ehu...@gmail.com wrote:
 
 idk if this is an interest for you guys but a part of the
 documentation I
 was thinking of adding a vagrant build solution. If you havnt
 heard
 of
 vagrant its just a virtual machine organiser+. Let me know if you
 think
 pushing this forward would help fix the problem of people not
 trying
 out
 the release candidates and ill put it to the top of my tbd's.
 
 On 27 May 2015 at 21:14, Ali Lown a...@lown.me.uk wrote:
 
 Yuri,
 
 Yep. I will be free again to put in some time this weekend to
 look at
 this.
 
 I think that I must have broken the third-party jars that enable
 federation some time when I tidied them all up a while back.
 This wasn't found earlier because:
 1) Nobody tried a completely clean build including re-fetching
 all the
 third-party objects
 2) The binary releases you produced were made using the old jars
 - so
 contain one of the missing packages, hence the binary artifacts
 were
 working fine when tested.
 
 Things to note then:
 1) Just because the binary artifacts work, they might not be the
 same
 as the source artifacts
 2) Always generate releases from a completely clean check out and
 run
 everything again.
 
 We were so close...
 Ali
 
 On 27 May 2015 at 08:33, Yuri Z vega...@gmail.com wrote:
 It looks like the wave release got stuck again. Anyways, let's
 discuss
 discuss how can we handle this...
 
 On Sun, May 17, 2015 at 5:21 PM Yuri Z vega...@gmail.com
 wrote:
 
 I tested by checking out the RC 9 branch and fetching
 jars/building
 - it
 worked fine. I didn't check federation.
 
 
 On Thu, May 7, 2015 at 1:25 PM Ali Lown a...@lown.me.uk
 wrote:
 
 If you fetch the jars do you have the same error trying to
 start
 the
 server?
 
 Ali
 On 7 May 2015 07:46, Yuri Z vega...@gmail.com wrote:
 
 I didn't fetched the jars - just copied them from existing
 folder.
 
 On Thu, May 7, 2015 at 9:44 AM Yuri Z vega...@gmail.com
 wrote:
 
 I see, what was the issue with federation?
 
 On Thu, May 7, 2015 at 3:00 AM Ali Lown a...@lown.me.uk
 wrote:
 
 -1 due to the inability to start the server with federation
 enabled.
 (I will change this to +1 if this is me failing to build
 correctly).
 
 Checked:
 - SHA512 hashes and GPG signs
 - Built using JDK7 and ran tests
 - Checked README, CHANGES, KEYS, RELEASE-NOTES,
 build.properties
 - Started server without federation using file backends.
 Tested
 wave
 creation, simple editing, etc.
 - Artifact naming seems good.
 - Was unable to start server with federation (missing
 org/xmpp/component/Log). Seems like a problem with the
 whack.jar
 file
 that is fetched during build. This is making me wonder how
 it
 worked
 in the RC8 binary package? @Yuri: Do you get the same error
 here,
 or
 do you get something different when you build from the
 artifact
 in a
 clean folder?
 
 Ali
 
 On 5 May 2015 at 18:23, Yuri Z vega...@gmail.com wrote:
 Great, thanks Ali. I checked that the source compiles and
 runs.
 On Tue 5 May 2015 at 17:39 Ali Lown a...@lown.me.uk
 wrote:
 
 I think we may wish to extend the vote duration, as no-one
 seems
 to
 have responded.
 
 I have just gotten around to this email in my inbox, so
 hope
 to
 get
 to
 this this evening...
 
 Ali
 
 
 
 On 29 April 2015 at 20:44, Yuri Z vega...@gmail.com
 wrote:
 RC9 is now available for review.
 Artifacts can be found here:
 https://dist.apache.org/repos/dist/dev/incubator/wave/0.4.0-rc9
 (Remember checksums are from 'gpg --print-md SHA512 $f 
 $f.sha')
 This time I included only source artifacts.
 
 The release version will be: 0.4.0-incubating
 
 This is taken from branch
 https://git-wip-us.apache.org/repos/asf?p=incubator-wave.git;a=shortlog;h=refs/heads/0.4.0-RC9
 
 Reminder on what included previous release 

Re: RC7 Vote Release

[Michael MacFadden]

Ali,

Adding them now.  First one is in.




On 4/4/15, 12:30 PM, Ali Lown a...@lown.me.uk wrote:

@Michael: What CSS type issues are these? Could you raise a JIRA issue for it?

Ali

On 4 April 2015 at 19:58, Michael MacFadden michael.macfad...@gmail.com 
wrote:
 All,

 I installed the RC on OS X and on Windows 7.  Ran fine on both.  Tested the 
 UI out in Chrome, FF, and IE.  As usual a few CSS type issues, but no 
 blockers.

 Again.. +1.



 On 4/4/15, 11:24 AM, Yuri Z vega...@gmail.com wrote:

+1 I tested install and went over licenses in source files (we still have a
lot of files with multiple license headers in them), checked NOTICE,
DISCLAIMER, CHANGES, THANKS, LICENSE and RELEASE-NOTES files.

On Sat, Apr 4, 2015 at 7:53 PM Ali Lown a...@lown.me.uk wrote:

 +1.

 Tested install, federation, memory and file backends.

 Ali

 On 2 April 2015 at 14:38, Ali Lown a...@lown.me.uk wrote:
  I have so far tested the SHA digest, GPG signature, and the
  KEYS/CHANGES/RELEASE-NOTE files, all are fine.
 
  I intend to test federation tomorrow to check it isn't broken.
 
  Has anyone checked the file copyright notices?
 
  Ali
 
  On 2 April 2015 at 00:31, Michael MacFadden michael.macfad...@gmail.com
 wrote:
  +1
 
 
 
 
  On 4/1/15, 3:04 PM, Dave Ball w...@glark.co.uk wrote:
 
 +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/incubator/wave/
 0.7-incubating/*
  (Remember checksums are from 'gpg --print-md SHA512 $f  $f.sha')
 
  The release version will be: 0.4.0-alpha
 
  This is taken from branch
  *https://git-wip-us.apache.org/repos/asf?p=incubator-
 wave.git;a=shortlog;h=refs/heads/0.4.0-RC7
  https://git-wip-us.apache.org/repos/asf?p=incubator-
 wave.git;a=shortlog;h=refs/heads/0.4.0-RC7*
 
  Reminder on what included previous release candidates:
  RC6 included:
  - Bug Fixes
 
  RC5 included:
  - Added MongoDB based deltas store and migration tool for deltas
 migration
  from file to mongo based store.
 
  - Added client/server profiling.
  - Added Atmosphere framework as replacement of Socket.IO.
  - Added alternative - Gmail style initials avatars.
  - Decreased number of permutations in dev compilation and added GWT
  superdev mode.
  - Upgraded the server to Jetty 9.1.1.
  - Added JDK 7 compatibility.
 
  RC4 included:
  - More licensing fixes
  - Federation works
  - New and updated translations
  - And more...
 
  A summary of useful information can be found in RELEASE-NOTES, and a
 list
  of changes in CHANGES at the above artifact distribution url, as well
 as
  being included in the tarballs/zips.(zipballs?)
 
  *Action Required:*
  *Test the release and make it works on your environment - at least
 standard
  configurations. Please go over the source files and make sure they
 don't
  contain anything that cannot be released under Apache Wave due to
 legal
  issues.*
 
  This vote will close around  GMT 8-th April 2015.
 
  [ ] +1   Release it!
  [ ] +0   OK, but...
  [ ] -0OK, but you really should fix
  [ ] -1Definitely not because...
 
  Thanks
 
 
 

Re: Coming Months

[Michael MacFadden]

I would be happy to participate.  Perhaps the first thing to know is.. What 
time zones people are all in.  I am in US Pacific Time Zone (UTC -7:00).

~Michael




On 4/2/15, 7:40 AM, Evan Hughes ehu...@gmail.com wrote:

sure, just need to know what time of day is suitable for the speakers as we
should keep a record of it for people to view whenever. Thanks to the other
threads there's plenty of stuff to compile a list of talking points, I'll
put something together over the next week.

On 2 April 2015 at 23:33, Ali Lown a...@lown.me.uk wrote:

 I think another hangout would be a great thing to have.

 @Evan: Are you happy to organise this?

 Ali

 On 1 April 2015 at 16:23, John Blossom jblos...@gmail.com wrote:
  Id be glad to listen in, but since I am not a technical contributor, I
 will
  try mostly just to monitor.
 
  All the best,
 
  John Blossom
 
  email: jblos...@gmail.com
  phone: 203.293.8511
  google+: google.com/+JohnBlossom
 
  On Mon, Mar 30, 2015 at 11:26 PM, Evan Hughes ehu...@gmail.com wrote:
 
  Hey all,
 
  could we get a Google hangout of the Mentors and contributors to
 solidify
  the direction which wave will be heading and pointing out what needs to
 be
  done other than just thoughts on the mailing list.
 

Re: RC7 Vote Release

[Michael MacFadden]

All,

I installed the RC on OS X and on Windows 7.  Ran fine on both.  Tested the UI 
out in Chrome, FF, and IE.  As usual a few CSS type issues, but no blockers.

Again.. +1.



On 4/4/15, 11:24 AM, Yuri Z vega...@gmail.com wrote:

+1 I tested install and went over licenses in source files (we still have a
lot of files with multiple license headers in them), checked NOTICE,
DISCLAIMER, CHANGES, THANKS, LICENSE and RELEASE-NOTES files.

On Sat, Apr 4, 2015 at 7:53 PM Ali Lown a...@lown.me.uk wrote:

 +1.

 Tested install, federation, memory and file backends.

 Ali

 On 2 April 2015 at 14:38, Ali Lown a...@lown.me.uk wrote:
  I have so far tested the SHA digest, GPG signature, and the
  KEYS/CHANGES/RELEASE-NOTE files, all are fine.
 
  I intend to test federation tomorrow to check it isn't broken.
 
  Has anyone checked the file copyright notices?
 
  Ali
 
  On 2 April 2015 at 00:31, Michael MacFadden michael.macfad...@gmail.com
 wrote:
  +1
 
 
 
 
  On 4/1/15, 3:04 PM, Dave Ball w...@glark.co.uk wrote:
 
 +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/incubator/wave/
 0.7-incubating/*
  (Remember checksums are from 'gpg --print-md SHA512 $f  $f.sha')
 
  The release version will be: 0.4.0-alpha
 
  This is taken from branch
  *https://git-wip-us.apache.org/repos/asf?p=incubator-
 wave.git;a=shortlog;h=refs/heads/0.4.0-RC7
  https://git-wip-us.apache.org/repos/asf?p=incubator-
 wave.git;a=shortlog;h=refs/heads/0.4.0-RC7*
 
  Reminder on what included previous release candidates:
  RC6 included:
  - Bug Fixes
 
  RC5 included:
  - Added MongoDB based deltas store and migration tool for deltas
 migration
  from file to mongo based store.
 
  - Added client/server profiling.
  - Added Atmosphere framework as replacement of Socket.IO.
  - Added alternative - Gmail style initials avatars.
  - Decreased number of permutations in dev compilation and added GWT
  superdev mode.
  - Upgraded the server to Jetty 9.1.1.
  - Added JDK 7 compatibility.
 
  RC4 included:
  - More licensing fixes
  - Federation works
  - New and updated translations
  - And more...
 
  A summary of useful information can be found in RELEASE-NOTES, and a
 list
  of changes in CHANGES at the above artifact distribution url, as well
 as
  being included in the tarballs/zips.(zipballs?)
 
  *Action Required:*
  *Test the release and make it works on your environment - at least
 standard
  configurations. Please go over the source files and make sure they
 don't
  contain anything that cannot be released under Apache Wave due to
 legal
  issues.*
 
  This vote will close around  GMT 8-th April 2015.
 
  [ ] +1   Release it!
  [ ] +0   OK, but...
  [ ] -0OK, but you really should fix
  [ ] -1Definitely not because...
 
  Thanks
 
 
 

Re: RC7 Vote Release

[Michael MacFadden]

+1




On 4/1/15, 3:04 PM, Dave Ball w...@glark.co.uk wrote:

+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/incubator/wave/0.7-incubating/*
 (Remember checksums are from 'gpg --print-md SHA512 $f  $f.sha')

 The release version will be: 0.4.0-alpha

 This is taken from branch
 *https://git-wip-us.apache.org/repos/asf?p=incubator-wave.git;a=shortlog;h=refs/heads/0.4.0-RC7
 https://git-wip-us.apache.org/repos/asf?p=incubator-wave.git;a=shortlog;h=refs/heads/0.4.0-RC7*

 Reminder on what included previous release candidates:
 RC6 included:
 - Bug Fixes

 RC5 included:
 - Added MongoDB based deltas store and migration tool for deltas migration
 from file to mongo based store.

 - Added client/server profiling.
 - Added Atmosphere framework as replacement of Socket.IO.
 - Added alternative - Gmail style initials avatars.
 - Decreased number of permutations in dev compilation and added GWT
 superdev mode.
 - Upgraded the server to Jetty 9.1.1.
 - Added JDK 7 compatibility.

 RC4 included:
 - More licensing fixes
 - Federation works
 - New and updated translations
 - And more...

 A summary of useful information can be found in RELEASE-NOTES, and a list
 of changes in CHANGES at the above artifact distribution url, as well as
 being included in the tarballs/zips.(zipballs?)

 *Action Required:*
 *Test the release and make it works on your environment - at least standard
 configurations. Please go over the source files and make sure they don't
 contain anything that cannot be released under Apache Wave due to legal
 issues.*

 This vote will close around  GMT 8-th April 2015.

 [ ] +1   Release it!
 [ ] +0   OK, but...
 [ ] -0OK, but you really should fix
 [ ] -1Definitely not because...

 Thanks

Re: Roadmap

[Michael MacFadden]

I mainly agree with Yuri.  I personally believe that the first steps should be 
addressing the part that make I hard for new developers to come in and help.

Build System… replacing obscure technologies… developer docs. Separation of UI 
from server… etc.




On 3/25/15, 3:08 AM, Dave Ball w...@glark.co.uk wrote:


It might be a little out of date, but:
https://cwiki.apache.org/confluence/display/WAVE/Source+Code+Organization
might be a good start for anyone wanting to work on the client / server 
/ common split.  Anything with an x in both client and server columns 
would obviously be common! ;-)
[Pablo: I don't know if your work already covers this, and is mergable 
back into wave?]

John - long term aspirations are incredibly important, but Wave's 
problems at the moment aren't due to a lack of aspiration (there are 
plenty of great aspirations in the community, many of them shared by 
many of us).  My observation is that if wave is to survive at Apache we 
need a focus on manageable incremental improvements - getting more 
people involved in actually doing.[1]

The client-server protocol is currently defined in this protobufs file:
https://git-wip-us.apache.org/repos/asf?p=incubator-wave.git;a=blob;f=src/org/waveprotocol/box/common/comms/waveclient-rpc.proto
but is effectively an implementation detail of the current combined 
codebase.

Making a split between client and server (and common) will expose this 
interface and make it more visible. 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 talking, but not actually 
contributing to the codebase or documentation in a meaningful way. Being 
conscious of this, I try to keep out of most of the blue sky 
discussions myself. I don't want my aspirations becoming a distraction 
to people that have the time to actually do the changes that are of 
interest to them.

On 25/03/15 00:56, John Blossom wrote:
 Liking what I am hearing.

 My ten cents:

 client/server/common model is good for libraries, yes, but need
 well-defined client APIs to allow multiple apps to access common data
 stores. Otherwise you get more balkanisation and the data model never takes
 off.

 federation required, preferably in a way that will support sync/async
 collaboration and store-forward data models.

 Would like to see Wave 3.0 ideas considered.

 All the best,

 John Blossom

 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: google.com/+JohnBlossom

 On Tue, Mar 24, 2015 at 4:32 PM, Thomas Wrobel darkfl...@gmail.com wrote:

 On 24 March 2015 at 16:32, Dave Ball w...@glark.co.uk wrote:

   Might it be better to have three parts?
   - common
   - server
   - client

 Common would contain the document and concurrency model etc. Client and
 Server would both depend on Common. Common would compile to JS for the
 Client, but Server would depend directly on Common so wouldn't need to
 depend on the compiled javascript.


 +1
 I think this would be the best way to maintain compatibility between
 client(s) and sever(s). Downside is people making non-Java clients (or
 non-JS via GWT) would need their own common implementation.
 But it wouldnt be any worse then now.

Re: Raise your hands if you would like to participate

[Michael MacFadden]

+1

Although, only if we have some specific objectives, like getting a release, or 
mavenizing, or any other well defined task that we can move towards as a group.

More like +0 if it just random work on random issues that I am interested in 
knocking of in Jira.




On 3/23/15, 5:47 PM, Ali Lown a...@lown.me.uk wrote:

+1.

One of my main time-sink responsibilities is about to come to an end
(post an AGM later today).

Ali

On 23 March 2015 at 22:22, Vicente J. Ruiz Jurado v...@ourproject.org wrote:
 +0.5 (to be realistic)

Re: GSoC 2015 with Apache Wave

[Michael MacFadden]

[3] -
   
[image: Inline image 1]
   
   
On Thu, Mar 19, 2015 at 9:48 PM, Michael MacFadden 
michael.macfad...@gmail.com wrote:
   
Roshan,
   
There are plenty of tasks within Wave that could be worked on.  Do
  you
have any particular interest?  UI, Backend work, etc.?  I am sure
 we
   could
find you something.
   
~Michael
   
   
   
   
On 3/19/15, 5:33 AM, Roshan Lakmal roshan.2013...@iit.ac.lk
  wrote:
   
Hi all,

I'm Roshan Lakmal, an Undergraduate student from Informatics
   Institute of
Technology - Sri Lanka. Last year I participated Gsoc for Apache
   Software
Foundation (Apache SIS) [1].

For this summer I would like to work with Apache Wave for GSoC
 2015.
   Is
there any suitable task available for me.

[1] -

   
  
 
 http://www.google-melange.com/gsoc/project/details/google/gsoc2014/roshanrox911/5668600916475904

Cheers,

Roshan
   
   
   
  
 

Re: GSoC 2015 with Apache Wave

[Michael MacFadden]

Roshan,

There are plenty of tasks within Wave that could be worked on.  Do you have any 
particular interest?  UI, Backend work, etc.?  I am sure we could find you 
something.

~Michael




On 3/19/15, 5:33 AM, Roshan Lakmal roshan.2013...@iit.ac.lk wrote:

Hi all,

I'm Roshan Lakmal, an Undergraduate student from Informatics Institute of
Technology - Sri Lanka. Last year I participated Gsoc for Apache Software
Foundation (Apache SIS) [1].

For this summer I would like to work with Apache Wave for GSoC 2015. Is
there any suitable task available for me.

[1] -
http://www.google-melange.com/gsoc/project/details/google/gsoc2014/roshanrox911/5668600916475904

Cheers,

Roshan

Re: March 2015 Report

[Michael MacFadden]

All, I have updated the report on the wiki page for Wave.

~Michael




On 3/1/15, 12:50 PM, Ali Lown a...@lown.me.uk wrote:

Michael,

If you could write the report this quarter, that would be great!
(Though there hasn't exactly been a lot to write about...)

Ali

On 1 March 2015 at 18:56, Michael MacFadden michael.macfad...@gmail.com 
wrote:
 If not one else is able.  I am more than happy to help

 ~Michael




 On 2/28/15, 12:42 AM, Christian Grobmeier grobme...@apache.org 
wrote:

Any volunteers for this report?

On Fri, Feb 27, 2015, at 07:01, Marvin Humphrey wrote:

 Greetings, {podling} developers,

 The marvin automated report reminder script didn't fire for whatever
 reason this week, so I'm sending out a bulk reminder manually for the 
18
 podlings who are expected to submit a March 2015 report.  Boilerplate
 repinder text below.

 Best,

 Marvin Humphrey

 ---

 Dear podling,

 This email was sent by an automated system on behalf of the Apache
 Incubator PMC. It is an initial reminder to give you plenty of time to
 prepare your quarterly board report.

 The board meeting is scheduled for Wed, 18 March 2015, 10:30 am PST.
 The report for your podling will form a part of the Incubator PMC
 report. The Incubator PMC requires your report to be submitted 2 weeks
 before the board meeting, to allow sufficient time for review and
 submission (Wed, March 4th).

 Please submit your report with sufficient time to allow the incubator
 PMC, and subsequently board members to review and digest. Again, the
 very latest you should submit your report is 2 weeks prior to the 
board
 meeting.

 Thanks,

 The Apache Incubator PMC

 Submitting your Report

 --

 Your report should contain the following:

 *   Your project name
 *   A brief description of your project, which assumes no knowledge of
 the project or necessarily of its field
 *   A list of the three most important issues to address in the move
 towards graduation.
 *   Any issues that the Incubator PMC or ASF Board might wish/need to 
be
 aware of
 *   How has the community developed since the last report
 *   How has the project developed since the last report.

 This should be appended to the Incubator Wiki page at:

 http://wiki.apache.org/incubator/March2015

 Note: This is manually populated. You may need to wait a little before
 this page is created from a template.

 Mentors
 ---

 Mentors should review reports for their project(s) and sign them off 
on
 the Incubator wiki page. Signing off reports shows that you are
 following the project - projects that are not signed may raise alarms
 for the Incubator PMC.

 Incubator PMC

Re: March 2015 Report

[Michael MacFadden]

Ali,

I’ll type it up today.

~Michael




On 3/1/15, 12:50 PM, Ali Lown a...@lown.me.uk wrote:

Michael,

If you could write the report this quarter, that would be great!
(Though there hasn't exactly been a lot to write about...)

Ali

On 1 March 2015 at 18:56, Michael MacFadden michael.macfad...@gmail.com 
wrote:
 If not one else is able.  I am more than happy to help

 ~Michael




 On 2/28/15, 12:42 AM, Christian Grobmeier grobme...@apache.org 
wrote:

Any volunteers for this report?

On Fri, Feb 27, 2015, at 07:01, Marvin Humphrey wrote:

 Greetings, {podling} developers,

 The marvin automated report reminder script didn't fire for whatever
 reason this week, so I'm sending out a bulk reminder manually for the 
18
 podlings who are expected to submit a March 2015 report.  Boilerplate
 repinder text below.

 Best,

 Marvin Humphrey

 ---

 Dear podling,

 This email was sent by an automated system on behalf of the Apache
 Incubator PMC. It is an initial reminder to give you plenty of time to
 prepare your quarterly board report.

 The board meeting is scheduled for Wed, 18 March 2015, 10:30 am PST.
 The report for your podling will form a part of the Incubator PMC
 report. The Incubator PMC requires your report to be submitted 2 weeks
 before the board meeting, to allow sufficient time for review and
 submission (Wed, March 4th).

 Please submit your report with sufficient time to allow the incubator
 PMC, and subsequently board members to review and digest. Again, the
 very latest you should submit your report is 2 weeks prior to the 
board
 meeting.

 Thanks,

 The Apache Incubator PMC

 Submitting your Report

 --

 Your report should contain the following:

 *   Your project name
 *   A brief description of your project, which assumes no knowledge of
 the project or necessarily of its field
 *   A list of the three most important issues to address in the move
 towards graduation.
 *   Any issues that the Incubator PMC or ASF Board might wish/need to 
be
 aware of
 *   How has the community developed since the last report
 *   How has the project developed since the last report.

 This should be appended to the Incubator Wiki page at:

 http://wiki.apache.org/incubator/March2015

 Note: This is manually populated. You may need to wait a little before
 this page is created from a template.

 Mentors
 ---

 Mentors should review reports for their project(s) and sign them off 
on
 the Incubator wiki page. Signing off reports shows that you are
 following the project - projects that are not signed may raise alarms
 for the Incubator PMC.

 Incubator PMC

Re: Incubator PMC/Board report for Dec 2014 ([ppmc])

[Michael MacFadden]

Anything I can do to help with the release?

~Michael

 On Dec 3, 2014, at 12:49 AM, Yuri Z vega...@gmail.com wrote:
 
 Ok, I updated the wiki, please review/edit.
 
 On Mon Dec 01 2014 at 4:58:34 PM Ali Lown a...@lown.me.uk wrote:
 
 Yuri,
 
 That sounds like a great plan.
 
 I would love to help, but am swamped this week.
 
 Thanks,
 Ali
 
 On 1 December 2014 at 14:32, Yuri Z vega...@gmail.com wrote:
 Hi
 There wasn't a lot of activity recently, but I think we still need to do
 the release. I ll merge some changes that were already approved in the
 Review Board and post a new release candidate for reviewing/voting.
 On Mon Dec 01 2014 at 4:15:29 PM Marvin no-re...@apache.org wrote:
 
 
 
 Dear podling,
 
 This email was sent by an automated system on behalf of the Apache
 Incubator PMC.
 It is an initial reminder to give you plenty of time to prepare your
 quarterly
 board report.
 
 The board meeting is scheduled for Wed, 17 December 2014, 10:30 am PST.
 The report
 for your podling will form a part of the Incubator PMC report. The
 Incubator PMC
 requires your report to be submitted 2 weeks before the board meeting,
 to
 allow
 sufficient time for review and submission (Wed, Dec 3rd).
 
 Please submit your report with sufficient time to allow the incubator
 PMC,
 and
 subsequently board members to review and digest. Again, the very latest
 you
 should submit your report is 2 weeks prior to the board meeting.
 
 Thanks,
 
 The Apache Incubator PMC
 
 Submitting your Report
 --
 
 Your report should contain the following:
 
 * Your project name
 * A brief description of your project, which assumes no knowledge of
 the
 project
   or necessarily of its field
 * A list of the three most important issues to address in the move
 towards
   graduation.
 * Any issues that the Incubator PMC or ASF Board might wish/need to be
 aware of
 * How has the community developed since the last report
 * How has the project developed since the last report.
 
 This should be appended to the Incubator Wiki page at:
 
  http://wiki.apache.org/incubator/December2014
 
 Note: This is manually populated. You may need to wait a little before
 this page
  is created from a template.
 
 Mentors
 ---
 Mentors should review reports for their project(s) and sign them off on
 the
 Incubator wiki page. Signing off reports shows that you are following
 the
 project - projects that are not signed may raise alarms for the
 Incubator
 PMC.
 
 Incubator PMC
 

Re: JSON editing and move conflicts

[Michael MacFadden]

Joseph,

I¹d like to drill into the directory structure mapping concept a bit.  Can
you epand on the use case where you think ShareJS would be used to map to a
directory structure?  I think thing this would help us understand some of
the challenges.

~Michael

From:  Richard Davis richardc...@gmail.com
Reply-To:  wave-dev@incubator.apache.org
Date:  Monday, October 20, 2014 at 6:53 PM
To:  shar...@googlegroups.com
Cc:  wave-dev@incubator.apache.org, derb...@googlegroups.com
Subject:  Re: JSON editing and move conflicts

Hi Joseph,

Regarding object move, I'm in favor of keeping things simple, but I'm also
in favor of thinking about this in terms of what people might actually do
with this capability. Since mapping a directory structure of files is the
one good example you have, then maybe multiple moves to the same key should
merge their values as directory moves merge their files. That would mean a
slightly modified version of your option 1. In the simple case, you have
{x:1, y:2} - {z:2}, but in the complex case you have {x:{a:1}, y:{b:2}} -
{z:{a:1, b:2}}. 

Maybe you could add a flag that allows the writer to specify whether they
want a move to replace the existing value (your option 1) or merge with
the existing value (this modified option 1). It's still clear what will
happen if two writers use two different flags, as long as you can put the
two ops in some order: if the replace comes second you can replace, and if
the merge comes second you can merge.

The only downside I see of merging is that it can have a cascading effect.
That could be tricky, and I haven't thought it through, but I had hope that
this wouldn't be fundamentally different from the other changes you are
making in JSON2.

-Richard

On Sunday, October 19, 2014 8:46:11 AM UTC+8, Joseph Gentle wrote:
 It does complicate the type, and it breaks my nice abstraction. Also
 remember that any funny logic will need to be on the server and the
 client - and I'd really like the server to be application-agnostic if
 possible. That said, the server will probably need
 application-specific schema validation  access control code anyway,
 so maybe its not a big deal.
 
 Another option is to just do the dangerous thing for objects, but
 actively encourage people to use lists instead. If you're inserting
 into a list instead of inserting into an object, the semantics are
 safe  easy. The final list will just contains both items. For
 hierarchal to-do lists, you probably want a children:[] list on your
 nodes anyway. Using object-move when the key is either a GUID or a
 hash of the data would work fine as well because your keys won't
 conflict. 
 
 This won't work if you're trying to map a directory structure of files
 though. But thats the only bad use case I can think of. Maybe
 something as simple as a flag on the move operation saying in the
 case of conflicts, rewrite the destination key to {key}_n. Or we
 could just force the IDE to use a list of files, and leave deduping
 hacks there. 
 
 -J 
 
 
 
 On Sat, Oct 18, 2014 at 4:44 PM, Ali Lown a...@lown.me.uk javascript: 
 wrote: 
  Hi Joseph, 
  
  I think that the only sensible option is to delegate the resolution of
  this action in the case of conflict back into the application, so some
  sort of extension of (4) that allows some arbitrary lambda expression
  to be passed as the onconflict method. (Depending on the situation,
  they might want to 'merge' the two items (if possible), rather than
  moving one into a 'backup' location).
  
  This does complicate the OT type, and does make it more difficult to
  analyse how long certain actions will take to resolve though...
  
  How does this sound?
  
  Ali 
  
  On 19 October 2014 00:33, Joseph Gentle jos...@gmail.com javascript: 
 wrote: 
  I'm (finally!) taking a serious look at making a better version of the
  JSON OT type. I'm cross-posting this here because it directly effects
  sharejs  derby users, and I think any serious rewrite of wave will
  use something like this at the top level to store waves.
  
  I have two questions that I would love some input on from the wider
 community. 
  
  We want to add a 'move' action which will let you transplant arbitrary
  parts of the JSON structure to other places in the tree. This is
  really useful if, for example, you want a hierarchal to-do list, a
  tree of source files for your IDE or a tree of blips.
  
  But I can't figure out what should happen if two users move different
  objects to the same place in the tree at the same time.
  
  1. The simplest option is to simply delete one of them. This is really
  convenient from a programming pov, but I think that would be the worst
  kind of surprise. {x:1, y:2} - {z:2}
  2. We could try and make one of the moves fail - {x:1, y:2} - {x:1,
  z:2}. On the face of it this sounds great, but this is a cascading
  failure. If (locally) I move x-z then insert some new data at x, what
  happens to the new data? Does the new data get deleted? Does x get
 

Re: JSON editing and move conflicts

[Michael MacFadden]

Bruno,

Using lists of lists alleviates of the issues that Joseph mentions with
object properties.  With nested list there are safe and easy ways to
handle these types of conflicts since we can increment array indices with
predictable and non-destructive outcomes.  You point about lambdas is
correct.  Depending on how you implmenet it, you may just move the problem
from that of the conflicting object properties to that of the conflicting
lambdas.

Michael

On 10/19/14, 3:35 AM, Bruno Gonzalez (aka stenyak) sten...@stenyak.com
wrote:

 

Renamed keys for user-facing dicts, and application lambdas for
user-hidden dicts sounds reasonable to me.

What about different lambdas affecting each other while they run? E.g.
two client-side lambdas trying to solve the same conflict. Or also,
since lambdas can potentially do *anything* in the json data,
server-side lambdas may affect other concurrent lambdas that weren't
even working on the very same conflict. Would a global conflict lock be
used to prevent it, or is there any strategy to guarantee these issues
won't happen? 

I'm assuming ditching json for a simpler format (just lists of lists),
delegating dictionary implementation to each application, is either a
dumb idea, or just another variant of same original problem (since I
guess we would end up providing a dictionary emulation library using
lists of (key,value) lists anyway, which applications may or may not
use, so exactly like current situation with lists and dicts).

-- 

Regards/Saludos,
 Bruno Gonzalez

http://www.stenyak.com | stenyak @ irc://irc.freenode.net
 

Re: RC6 available for pre-view

[Michael MacFadden]

With regards to the versioning scheme.  This is on I have used before.  I
am a +1 for following this.  The nice thing is that if some one asked
about the versions we can simply point them to the page you linked rather
than having to justify it ourselves.

~Michael

On 8/28/14, 11:56 PM, Yuri Z vega...@gmail.com wrote:

I think we should discuss the versioning. I adopted the http://semver.org/
for RC6. So the RC6 version looks like: 0.4.0-rc.6-incubating

And the release version will be 0.4.0.

Any thoughts?
On Aug 29, 2014 7:37 AM, Michael MacFadden michael.macfad...@gmail.com
wrote:

 All,

 Very nice.  I am doing some testing on the demo right now.  Thus far
 nothing major to report.  What are the main things we should be
reviewing
 for RC6?  I have been following the licensing discussion.  Anything
else?

 ~Michael

 On 8/28/14, 3:10 PM, Yuri Z vega...@gmail.com wrote:

 Hi
 Please preview/review the RC6 at
 
 
https://dist.apache.org/repos/dist/dev/incubator/wave/0.4.0-rc.6-incubati
n
 g/
 There's also a demo server for RC6 -
 
 
http://ec2-23-22-27-34.compute-1.amazonaws.com:9898/#waveinabox.net/w+kVx
c
 CWkLmsA

Re: RC6 available for pre-view

[Michael MacFadden]

All,

Very nice.  I am doing some testing on the demo right now.  Thus far
nothing major to report.  What are the main things we should be reviewing
for RC6?  I have been following the licensing discussion.  Anything else?

~Michael

On 8/28/14, 3:10 PM, Yuri Z vega...@gmail.com wrote:

Hi
Please preview/review the RC6 at
https://dist.apache.org/repos/dist/dev/incubator/wave/0.4.0-rc.6-incubatin
g/
There's also a demo server for RC6 -
http://ec2-23-22-27-34.compute-1.amazonaws.com:9898/#waveinabox.net/w+kVxc
CWkLmsA

Re: [VOTE] Release Wave 0.5 based on RC5

[Michael MacFadden]

+1

On 7/21/14, 12:08 PM, Andrew Kaplanov akapla...@gmail.com wrote:

+1.

Re: Current Release Status

[Michael MacFadden]

Ok, I’ll get that updated.

On 7/19/14, 10:02 AM, Yuri Z vega...@gmail.com wrote:

The download page should refer to the official releases location at
https://dist.apache.org/repos/dist/release/incubator/wave/


On Mon, Dec 23, 2013 at 4:24 AM, Michael MacFadden 
michael.macfad...@gmail.com wrote:

 Ok that makes sense.  I will start working on the downloads section.  I
 would like to get back in to coding after the release is done.  Also
 potentially reviving the maven build.  But for now, I think working on
the
 web site will help let you all focus on code and release.  So that is
what
 I will do to contribute for now!

 ~Michael

 On 12/22/13, 7:20 PM, Ali Lown a...@lown.me.uk wrote:

  Great news on GIT.  I think that will hep us immensely.  I have been
  following a lot of the mailing list.  Actually I spent quite while
 reading
  the list over the last few days.
 
 Yes. Subversion has been a point of 'stickiness' with new devs in the
 past, and the workflow was quite convoluted.
 
  From an Apache perspective, I do think that since we have been
 incubating
  for several years now, it is important for us to make a release soon
if
 we
  are to stay in this community.  We need to demonstrate some forward
  progress.
 
 Indeed. We have spent most of this year iterating through the previous
 4 release candidates, so I think it would be hard to argue that we
 have made no forward progress.
 Getting the first release (on such a large codebase) is quite
 challenging, but I think we are now quite close to being in a suitable
 state for thorough inspection by the rest of the Incubator.
 
  So it sounds like we need to get through the search feature, then
turn
  back to an RC5 release?
 
 Yep. Making the release once the search feature is pushed is a few
hours
 work.
 Then, we want votes. Lots of votes. :)
 
  What about the web site.  We don¹t really have a spot to advertise
  releases. For a smooth re-entry, I could start to work on that as a
  non-critical-path task, so that when we are ready to release the web
 site
  is ready.
 
 I haven't worked on that bit yet, since none of the RCs came close
enough.
 If you could actually build the 'release download section' - which
 needs to make use of the Apache mirroring system - then that would be
 really useful!
 (Using the sample stuff on the wiki it can be thrown together in a few
 hours, but a polished, well-integrated download flow needs a bit more
 thought to link in to our existing site)
 
 More user documentation on the wiki (and actually pointing them to the
 wiki on the download/post-download page) is also always good!
 
 Ali

Re: An Open Source implementation of Google Drive Realtime API

[Michael MacFadden]

Random question. You mention. GR, Wave, and Etherpad. What is GR?

~Michael

 On Jul 9, 2014, at 10:39 AM, Kythyria kythy...@gmail.com wrote:
 
 On 07/09/14 16:25, Thomas Wrobel wrote:
 Of what benefit would contributing this to wave be?
 
 Doesn't wave do a superset of this functionality already? (albeit with
 messier code)
 In a similar way to XML being a superset of JSON (and Wave includes bits that 
 *neither* does well or indeed at all).
 
 Seems (possibly) more useful for Wave to contribute its (federation)
 functionality to this or a fork of it. Then you would have a new
 pseudo-wave that does much of the same stuff, but with a much neater
 codebase (and mobile support) to build from.
 Alternatively if elements of this could replace waves code to
 simplify/neaten it that might be good...but at least from an outsiders
 perspective that seems rather hard.
 
 Regarding the point earlier about rich text in json - wouldn't it be easier
 to use html encoding of styled text? To my knowledge html strings work in
 json just fine as long as a few things are escaped. Or isnt this possible
 with the OT method being used?
 
 HTML strings fit in JSON--and technically it's not JSON we're talking about 
 but the data structures JSON serialises--the problem is that then you're 
 editing a textual serialisation, rather than the actual data structure. Given 
 that GR, Wave, and Etherpad all use something other than a plain text string, 
 it's probably reasonable to conclude that using plain strings to represent 
 rich text opens too many possibilities for an OT or similar system to get 
 into a state where the document is unparseable.
 
 Or for that matter, for creating pairs of operations which cannot be resolved 
 in any reasonable way by an algorithm that isn't aware of the syntax involved.

Re: Release

[Michael MacFadden]

All,

Although I have been dormant.  I am willing to help out with the release
in any way possible.  If you need some one to go through the release and
test it.  Or post it up to he web site once we have it ready let me know.
I haven¹t helped out in a while, so I would love to contribute.

~Michael

On 7/12/14, 6:05 AM, Ali Lown a...@lown.me.uk wrote:

Yuri,

AFAIK both of these can be TODOs can be removed now.

Thanks,
Ali

On 12 July 2014 14:01, Yuri Z vega...@gmail.com wrote:
 Ok, great. This is a great Wiki. I ll try to go the steps and later to
add
 a release job to jenkins so the release process will be automated. Off
 course if someone want to help with release stuff - it would be great :)
 The wiki contains two todos:
 1. ODO: Do we need Extension-Name, Implementation-Vendor-Id as well?
 2. Check export status of any cryptographic dependencies. (Unknown
 currently whether we need an ECCN or not)

 Regarding the 2- I think we got rid of it, is it right?
 Regarding 1 - @Ali can you comment?


 On Sat, Jul 12, 2014 at 3:43 PM, Ali Lown a...@lown.me.uk wrote:

 Yuri,

 I started writing up the 'procedure' here:
 https://cwiki.apache.org/confluence/display/WAVE/Release+Procedure It
 needs updating now that we use git rather than svn.

 If we could get jenkins building the releases that would be great!
 (wave-artifacts doesn't seem to be generating the src releases?)

 Once the artifacts are made (ant release, or equivalent), then the
 next step is to manually verify the contents are as expected, and to
 sign it.
 I have a very small script to sign all the files using my key, and to
 generate the SHA512 sums for the files: http://pastebin.com/05wBkWd1

 Once that is done, send it to the wave list to vote upon...
 Once that is done, send it to the incubator list to vote upon...
 Once that is done, release! ;)

 Ali

 On 12 July 2014 13:21, Yuri Z vega...@gmail.com wrote:
  Thanks for update Ali.
  I think the release is important to show that we handled all the
 copyright
  issues, so I would prefer just to release as is and then add the
patch
  later.
  Anyway, let's try to do the release stuff for rc 05. Are there any
 scripts
  that should be run? What is the procedure?
  By the way, I already added a Jenkins job to create the release
artifact
 -
  https://builds.apache.org/view/S-Z/view/Wave/job/wave-artifacts/
  So, if could to automate the licenses verification and signing we
could
  release just by running the job in Jenkins...
 
 
 
 
  On Sat, Jul 12, 2014 at 2:56 PM, Ali Lown a...@lown.me.uk wrote:
 
  RC4 was merged back in to master around January, and development has
  continued in master from there..
 
  I don't recall any major show stoppers with RC4. A look at the vote
  thread suggests that the only problems left to discuss were the
images
  in thumbnail_patterns, for which we could find no copyright
  assignment. But we fixed this problem in 48c3bc9, by changing the
  thumbnails to some we could attribute.
 
  On a meta level, the problem at the time was that RC4 had a very
poor
  vote turnout, disincentivizing further work.
  (And on a personal level, I ran out of time I could put towards
Wave)
 
  I don't think there is anything stopping us putting together RC5
over
  this weekend.
  (Since we would want to take from current master, a check of the
  licenses will be required to be redone).
 
  Is there interest in RC5?
  (And do we want to put Frank's fulltextsearch patches in?)
 
  Thanks,
  Ali
 
  On 12 July 2014 12:35, Yuri Z vega...@gmail.com wrote:
   I think I merged the rc 0.4 into master a while ago. But I don't
 remember
   what were the issues that prevented from us to release rc 0.4.
   @Ali, so you remember what were the issues?
  
  
   On Sat, Jul 12, 2014 at 2:27 PM, Christian Grobmeier 
  grobme...@gmail.com
   wrote:
  
   Hi folks,
  
   before quite a while, we were discussing a release. It's still
not
  there,
   and I would like to know what the actual problem is.
  
   As you know, releases are considered a sign of a healthy project
in
 the
   incubator.
   It's currently discussed within the IPMC why projects which don't
 manage
   to make a release
   after a year should stay in the incubator.
  
   Regards,
   Christian
  
   ---
   http://www.grobmeier.de
   The Zen Programmer: http://bit.ly/12lC6DL
   @grobmeier
   GPG: 0xA5CC90DB
  
 

Re: An Open Source implementation of Google Drive Realtime API

[Michael MacFadden]

Hello,

I took a look at some of the code.  I see where the code implements some
transformation functions (for OT), but I do not see where something like a
Transformation Control Algorithm is implemented.

How do you determine which operations need to be transformed against which
other operations?

Regards,

Michael

On 7/7/14, 11:07 PM, 田传武 i...@goodow.com wrote:

Hi all,

I'd like to share an open-source project which implements nearly all
features of the google drive realtime api. *Google Drive Realtime API*
https://developers.google.com/drive/realtime/ provides Google Docs–style
instant collaboration. It lets multiple people edit the same data
simultaneously.

This project was inspired by Apache Wave, it is available on github at
https://github.com/goodow/realtime-store
The server runs on vert.x, and uses a memory store by default, but also
provides a persistent data store based on ElasticSearch and uses Redis to
scale across multiple frontend servers. The redis+elasticsearch code is
ported from livedb https://github.com/share/livedb,
really appreciate Joseph Gentle and the ShareJS community, thanks!

You can try out the features of the Realtime API on the *live playground*
http://realtimeplayground.goodow.com/, or get the *Android demo App*
https://play.google.com/store/apps/details?id=com.goodow.realtime.android
.playground
on
google play.
There is also an *Objective-C client library
https://github.com/goodow/GDStore* for iOS and Mac OS X, but it is not
yet fully tested, so please use at your own risk!

Enjoy!

Re: An Open Source implementation of Google Drive Realtime API

[Michael MacFadden]

Great that is what I was looking for.  So essentially this is using the
same concurrency control algorithm as both wave and walk around.  While
the code for the TCA for wave and walk around is different, the TCA core
algorithm (logic) is essentially the same.

On 7/8/14, 7:31 PM, 田传武 i...@goodow.com wrote:

inline

On Wed, Jul 9, 2014 at 10:18 AM, Michael MacFadden 
michael.macfad...@gmail.com wrote:

 Thanks.  I’ll need to look at the code a little more, but this appears
to
 handle transforming two operations (or two sets of operations).  In a
 collaborative systems built on OT, there are certain operations that
need
 to be transformed against each other and certain ones that do not.  For
 example if you generate an operation and I receive it, and incorporate
it
 into my document model, and THEN I issue a new operations, these do not
 need to be transformed.  The transformation control algorithm typically
 decides which operations are concurrent and which ones are not.


Right, see also:
https://github.com/goodow/realtime-store/blob/master/src/main/java/com/goo
dow/realtime/store/channel/TransformQueue.java
This is forked from the walkaround project.

Re: What's wrong with download links fro WIAB?

[Michael MacFadden]

Did some one publish the site?  I made these changes and committed them
(for the download links), but I didn¹t publish the changes to the
production site.

On 1/18/14, 1:07 PM, Yuri Z vega...@gmail.com wrote:

You can get the sources as described here:
http://incubator.apache.org/wave/source-code.html
And then follow the instructions in README on install it.


On Sat, Jan 18, 2014 at 10:18 PM, Viktor Nagornyy
vnagor...@viktorix.comwrote:

 Guys,
 We were trying to download WIAB, but all download links are either
broken
 or redirect to some weird sites.

 Viktor

Re: What's wrong with download links fro WIAB?

[Michael MacFadden]

No worries.  I will just add a banner at the top that says that these
links are pending the upcoming release.

On 1/18/14, 1:14 PM, Yuri Z vega...@gmail.com wrote:

I think I did, didn't notice there were some more changes. Sorry.


On Sat, Jan 18, 2014 at 11:10 PM, Michael MacFadden 
michael.macfad...@gmail.com wrote:

 Did some one publish the site?  I made these changes and committed them
 (for the download links), but I didn¹t publish the changes to the
 production site.

 On 1/18/14, 1:07 PM, Yuri Z vega...@gmail.com wrote:

 You can get the sources as described here:
 http://incubator.apache.org/wave/source-code.html
 And then follow the instructions in README on install it.
 
 
 On Sat, Jan 18, 2014 at 10:18 PM, Viktor Nagornyy
 vnagor...@viktorix.comwrote:
 
  Guys,
  We were trying to download WIAB, but all download links are either
 broken
  or redirect to some weird sites.
 
  Viktor
 

Re: Write access to the Wave Wiki

[Michael MacFadden]

Raphael,

I will add you now!

~Michael

On 12/25/13, 1:04 AM, Raphael Bircher r.birc...@gmx.ch wrote:

Hi all

It is possible to get write access to the wave wiki? My nick on the Wiki
is rbircher. I want to update the build instructions.

Greetings Raphael

Re: Write access to the Wave Wiki

[Michael MacFadden]

Yuri,

I am pretty sure you are already an Admin.  I will add Ali also.

~Michael

On 12/25/13, 11:21 AM, Yuri Z vega...@gmail.com wrote:

Michael, can you please add me and Ali as admins to Wiki and Jira? Cause
we
need backup in case you are not available.



On Wed, Dec 25, 2013 at 8:13 PM, Michael MacFadden 
michael.macfad...@gmail.com wrote:

 Raphael,

 I will add you now!

 ~Michael

 On 12/25/13, 1:04 AM, Raphael Bircher r.birc...@gmx.ch wrote:

 Hi all
 
 It is possible to get write access to the wave wiki? My nick on the
Wiki
 is rbircher. I want to update the build instructions.
 
 Greetings Raphael

Web Site Updates (Mainly Downloads)

[Michael MacFadden]

All,

I started updating the web site with a downloads section for when we make
our release.  I started simple and followed the basic instructions for a
mirrored distribution.  The main points were that you are supposed to use
the mirror script for the main artifacts but to use the apache servers only
for the file signatures.

For now I went with apache-wave-0.4-incubating.xxx² as the artifact name
citing the recommendation to put the name apache in there for branding and
conflict avoidance.  I also added the Œ-incubating¹ tag as well, as
required.

For sake of argument I assumed both a zip and tar.gz format.  We can of
course change this.

I added some verbiage (taken from another Apache TLP) around verification of
signatures.

What else do we want on the download page?

~Michael

Re: Write access to the Wave Wiki

[Michael MacFadden]

Done.

On 12/25/13, 11:22 AM, Michael MacFadden michael.macfad...@gmail.com
wrote:

Yuri,

I am pretty sure you are already an Admin.  I will add Ali also.

~Michael

On 12/25/13, 11:21 AM, Yuri Z vega...@gmail.com wrote:

Michael, can you please add me and Ali as admins to Wiki and Jira? Cause
we
need backup in case you are not available.



On Wed, Dec 25, 2013 at 8:13 PM, Michael MacFadden 
michael.macfad...@gmail.com wrote:

 Raphael,

 I will add you now!

 ~Michael

 On 12/25/13, 1:04 AM, Raphael Bircher r.birc...@gmx.ch wrote:

 Hi all
 
 It is possible to get write access to the wave wiki? My nick on the
Wiki
 is rbircher. I want to update the build instructions.
 
 Greetings Raphael

Re: Web Site Updates (Mainly Downloads)

[Michael MacFadden]

Oh yeahŠ

http://wave.staging.apache.org/wave/downloads.html

~Michael

From:  Michael MacFadden michael.macfad...@gmail.com
Date:  Wednesday, December 25, 2013 at 2:35 PM
To:  wave-dev@incubator.apache.org wave-dev@incubator.apache.org
Subject:  Web Site Updates (Mainly Downloads)

All,

I started updating the web site with a downloads section for when we make
our release.  I started simple and followed the basic instructions for a
mirrored distribution.  The main points were that you are supposed to use
the mirror script for the main artifacts but to use the apache servers only
for the file signatures.

For now I went with apache-wave-0.4-incubating.xxx² as the artifact name
citing the recommendation to put the name apache in there for branding and
conflict avoidance.  I also added the Œ-incubating¹ tag as well, as
required.

For sake of argument I assumed both a zip and tar.gz format.  We can of
course change this.

I added some verbiage (taken from another Apache TLP) around verification of
signatures.

What else do we want on the download page?

~Michael

Current Release Status

[Michael MacFadden]

All,

It¹s been a while since I have been able to contribute to the project.  I
would like to re-engage.

To that end, I was wondering where we are with the process of making a
release.  Could some one summarize where we are at?

Thanks

~Michael

Re: Current Release Status

[Michael MacFadden]

Ali (and everyone else),

Great news on GIT.  I think that will hep us immensely.  I have been
following a lot of the mailing list.  Actually I spent quite while reading
the list over the last few days.

The full text search feature looks very promising.  I have been following
the code reviews.  I think waiting for that to make the release makes
sense, since we don’t want to stifle the development momentum.

From an Apache perspective, I do think that since we have been incubating
for several years now, it is important for us to make a release soon if we
are to stay in this community.  We need to demonstrate some forward
progress.

So it sounds like we need to get through the search feature, then turn
back to an RC5 release?

What about the web site.  We don’t really have a spot to advertise
releases. For a smooth re-entry, I could start to work on that as a
non-critical-path task, so that when we are ready to release the web site
is ready.

~Thanks

On 12/22/13, 6:58 PM, Ali Lown a...@lown.me.uk wrote:

Michael (et al.),

Following on from RC4 there were only a few minor things left that
needed fixing:
1) Licenses of a few random files
2) Some icons in thumbnail_patterns/ which had some unknown licensing

(1) has been fixed for a while in the wave-0.4-release branch.
(2) was fixed within the last week by Vicente using some CC'd icons.

(2) has also recently brought to light some uncertain icons in
war/static (which we have inherited from the wave-protocol codebase)
but whose licensing is unknown.

Frank R. has presented us with a highly promising patch (currently
undergoing review and some major refactoring) to enable full-text
search - a sorely lacking feature.
This would be highly useful to get in to the release, so in effect RC5
is currently stalled on this feature being ready.

For more detail on all of this, please skim back through the list over
the last month (ish).

Ali

P.S. At some point, I am going to have to merge the stuff in
wave-0.4-release to do with the build-script, and licensing tweaks
back in to master. (As they have diverged again a bit). I think this
is best done after RC5.
P.P.S. Since you disappeared for a bit, we have migrated fully to Git!

On 22 December 2013 20:53, Michael MacFadden
michael.macfad...@gmail.com wrote:
 All,

 It¹s been a while since I have been able to contribute to the project.
I
 would like to re-engage.

 To that end, I was wondering where we are with the process of making a
 release.  Could some one summarize where we are at?

 Thanks

 ~Michael

Re: Current Release Status

[Michael MacFadden]

Ok that makes sense.  I will start working on the downloads section.  I
would like to get back in to coding after the release is done.  Also
potentially reviving the maven build.  But for now, I think working on the
web site will help let you all focus on code and release.  So that is what
I will do to contribute for now!

~Michael

On 12/22/13, 7:20 PM, Ali Lown a...@lown.me.uk wrote:

 Great news on GIT.  I think that will hep us immensely.  I have been
 following a lot of the mailing list.  Actually I spent quite while
reading
 the list over the last few days.

Yes. Subversion has been a point of 'stickiness' with new devs in the
past, and the workflow was quite convoluted.

 From an Apache perspective, I do think that since we have been
incubating
 for several years now, it is important for us to make a release soon if
we
 are to stay in this community.  We need to demonstrate some forward
 progress.

Indeed. We have spent most of this year iterating through the previous
4 release candidates, so I think it would be hard to argue that we
have made no forward progress.
Getting the first release (on such a large codebase) is quite
challenging, but I think we are now quite close to being in a suitable
state for thorough inspection by the rest of the Incubator.

 So it sounds like we need to get through the search feature, then turn
 back to an RC5 release?

Yep. Making the release once the search feature is pushed is a few hours
work.
Then, we want votes. Lots of votes. :)

 What about the web site.  We don¹t really have a spot to advertise
 releases. For a smooth re-entry, I could start to work on that as a
 non-critical-path task, so that when we are ready to release the web
site
 is ready.

I haven't worked on that bit yet, since none of the RCs came close enough.
If you could actually build the 'release download section' - which
needs to make use of the Apache mirroring system - then that would be
really useful!
(Using the sample stuff on the wiki it can be thrown together in a few
hours, but a polished, well-integrated download flow needs a bit more
thought to link in to our existing site)

More user documentation on the wiki (and actually pointing them to the
wiki on the download/post-download page) is also always good!

Ali

Re: Incubation status

[Michael MacFadden]

I would still be more than happy to press through the mavenization, but it
seemed like people were some what against the idea until we got the
release out the door historically.

Thoughts?

On 12/1/13, 5:37 PM, Frank R. renfeng...@gmail.com wrote:

It'll get slim once mavenized.


On Mon, Dec 2, 2013 at 6:06 AM, Angus Turner angusisf...@gmail.com
wrote:

 It is quite a large repo :)

 Thanks
 Angus Turner
 angusisf...@gmail.com



 On Mon, Dec 2, 2013 at 9:05 AM, Thomas Wrobel darkfl...@gmail.com
wrote:

  No problem, at the moment its still checking out.
  I'll note down any other issues other then those two as I get any.
  (Actually still on WindowsXP here ;) )
 
  ~~~
  Thomas  Bertines online review show:
  http://randomreviewshow.com/index.html
  Try it! You might even feel ambivalent about it :)
 
 
  On 1 December 2013 23:02, Angus Turner angusisf...@gmail.com wrote:
 
   Or a wave ;)
   On a more serious note this is something that needs doing - and
 something
   I've been meaning to do for a while. Start with a clean slate on
each
  major
   OS (Mac OSX, Ubuntu, Win8 and possibly WinXP) and write down exactly
 what
   needs doing or what errors come up.
  
   If you begin to do this it'd be great to document it somewhere like
the
   wiki..
  
   Thanks
   Angus Turner
   angusisf...@gmail.com
  
  
  
   On Mon, Dec 2, 2013 at 8:58 AM, Thomas Wrobel darkfl...@gmail.com
  wrote:
  
ora wave? ;)
It is sort-of on-topic to the earlier discussion as to how to get
 more
activity. But yes, it might be getting too sidetracked.
   
   
   
~~~
Thomas  Bertines online review show:
http://randomreviewshow.com/index.html
Try it! You might even feel ambivalent about it :)
   
   
On 1 December 2013 22:46, Angus Turner angusisf...@gmail.com
 wrote:
   
 A wiki page or a new thread might be better for this - kind of
off
topic...

 Thanks
 Angus Turner
 angusisf...@gmail.com



 On Mon, Dec 2, 2013 at 8:34 AM, Thomas Wrobel
darkfl...@gmail.com
 
wrote:

  ok, svn checkout;
 
  Note #1: Get an
  Error validating server certificate for
  https://svn.apache.org:443:
  Unknown certificate issuer.
  Fingerprint:
bc:5f:40:92:fd:6a:49:aa:f8:b8:35:0d:ed:27:5e:a6:64:c1:7a:1b
   Thawte, Inc., US
 
  I accept once and proceed.
 
  (I am just documenting anything that might put people off
getting
 started)
 
 
 
 
 
  ~~~
  Thomas  Bertines online review show:
  http://randomreviewshow.com/index.html
  Try it! You might even feel ambivalent about it :)
 
 
  On 1 December 2013 22:26, Thomas Wrobel darkfl...@gmail.com
  wrote:
 
   cheers :)
  
   ~~~
   Thomas  Bertines online review show:
   http://randomreviewshow.com/index.html
   Try it! You might even feel ambivalent about it :)
  
  
   On 1 December 2013 21:35, Yuri Z vega...@gmail.com wrote:
  
   The latest source code:
   http://incubator.apache.org/wave/source-code.html
  
  
   On Sun, Dec 1, 2013 at 8:19 PM, Thomas Wrobel 
   darkfl...@gmail.com
   wrote:
  
On 29 November 2013 16:05, Fleeky Flanco
fle...@gmail.com
wrote:
   

  

  
 https://cwiki.apache.org/confluence/display/WAVE/Building+Wave+in+a+Box

 https://cwiki.apache.org/confluence/display/WAVE/Home

 also there is  #wiab on irc.freenode.net
   
   
   
Ok, trying to follow this guide to setup for client
  development.
   
Stuck #1;
   
Wheres the latest source?
   
  
  
  
 

   
  
 

Re: Why does nobody vote on the release? (was: Fwd: Re: [VOTE] Release Wave 0.4 based on RC4)

[Michael MacFadden]

Hello,

I actually haven't seen the vote.  In fact.  Looking at my email I see a
grand total of about 15 emails on my entire gmail account since mid
September. 

I don't see the original vote email, nor the email I see forward below.
When was the vote.  I would like to go look back and ensure I am not
missing emails.

I used to see several emails a day.  I haven't seen anything much (no
commits, no votes, nothing from review board) for several weeks now come
to think of it.

~Michael

On 9/12/13 12:36 PM, Christian Grobmeier grobme...@gmail.com wrote:


Am 12.09.13 20:35, schrieb Ali Lown:
 It seems nobody else is able to give feedback at this point.
 Christian raised some things that are worth doing, so I may as well
 start again with RC5, which I will push up in a few weeks time. [It is
 a bit too busy for me ATM.]

 Hopefully, by being a bit later, people won't be on holiday, so will
 be able to review it. :P
I would say save the time for now.

It has been 2 weeks time for voting. This project has seen messages.
It's september, not mid of august.
We got 1 (!) community vote. Vincente mentioned he is away (thats fine)
and John is not so much into gory technical details (accepted so far).

But where were the others? Is it really holidays which prevents the
vote? Do we ALL have holidays at the same time?

Before we move on with a new RC, i would like to know from the people
listed here:
http://people.apache.org/committers-by-project.html#wave
why they didn't vote.**

Was it really holidays? No interest? No time?

It has been *a lot* of work for Ali to deal with the ASF release
procedures and kick out multiple RCs. It would be worth to know if he
should continue and if there will be any voters in the future. If there
is nobody who is willing to open a zip file, look into it and send out a
+1, then its really alarming. It took me 30 minutes or so to check the
release. This is not so much.

I have hoped the excitement in the project after John and a few others
appeared was so big that we would have managed to get a new release out
for review. If others, maybe Incubator Shepherds* look at this project
now, they would think: no community.

Please let me - us - know what you who are on the list above prevented
to vote**.

Cheers***
Christian

* Incubator Shepherds are Incubator PMC people, who look independently
from the mentor on the activity of the project and provide a second
insight for the report
** Of course I don't want you to speak out anything which should be kept
private - remember this is a public list. I just want to know: is there
a realistic chance that we ever get more than 3 votes? 3 are required to
get it out, but given the huge list of committers we should get more
votes.
*** I am not a native speaker - and I hope my email doesn't sound to
angry. I am not. I would be dissappointed if it finally turns out that
we have lost the energy and steam of the past days



 Ali

Re: Help me test algorithm performance

[Michael MacFadden]

I am in!

On 8/9/13 12:27 PM, John Blossom jblos...@gmail.com wrote:

Would love to help!

All the best,

John Blossom

email: jblos...@gmail.com
phone: 203.293.8511
google+: https://google.com/+JohnBlossom


On Thu, Aug 8, 2013 at 4:15 PM, Joseph Gentle jose...@gmail.com wrote:

 tldr; I need some volunteers to collaboratively edit a document
 together, so we can systematically evaluate algorithmic performance.


 So recently Michael linked me to a paper[1] which evaluates a bunch of
 different concurrency algorithms on speed  memory usage. They got a
 bunch of students to collaboratively edit two documents and used the
 operations generated in their benchmarks.

 The paper has some glaring omissions[2], and the data they gathered
 isn't publicly available. Of course, I also want to test Torben's
 algorithm to see how well it performs with realistic usage.

 So I'd like to reproduce their experiment. To do this I need a few
 volunteers to collaboratively edit some documents. We should construct
 realistic editing scenarios. The paper did two things:
 - Transcribe an episode of big bang theory
 - Write a report
 I'm open to suggestions on what we should do - we could also try
 collaborative creative writing, writing notes on a youtube video, or
 something. It doesn't really matter so long as the activity is
 focused, realistic (no keyboard mashing) and involves collaboration.
 (Sequential editing scenarios aren't interesting)

 To do this, I'll set up a special instance of ShareJS with ~1s of
 artificially induced latency and extra logging for the experiment. I
 want to run this experiment either late next week or on the weekend.

 The more experimental runs the better - although I suspect most of
 what we learn will be from the first couple logs.

 I will publish the raw data from the logs and send out a followup
 email. The experiment will be anonymous, but don't say anything you
 wouldn't want publicly known.

 How does that sound? Who's willing to help out?

 -J



 [1]
 
http://hal.archives-ouvertes.fr/docs/00/62/95/03/PDF/doce63-ahmednacer.pd
f
 [2] Criticisms:
 - Operations only insert or remove a single character, which means
 that a copy+paste that one of the users did resulted in 5000
 operations, each of which needed to be transformed individually.
 - Their text editor didn't batch changes - which is really stupid and
 unrealistic.
 - The students were all working locally (on a LAN), so there would
 have been fewer concurrent actions than we should realistically
 expect.

Re: Delving into OT

[Michael MacFadden]

What time is the meeting again?  I had voted on the alternative web site
along with some other folks.  I didn't see any slots that everyone could
meet.

On 7/29/13 6:45 AM, John Blossom jblos...@gmail.com wrote:

Michael, will you be able to join us on the Hangout this Wednesday?

All the best,

John Blossom

email: jblos...@gmail.com
phone: 203.293.8511
google+: https://google.com/+JohnBlossom


On Thu, Jul 25, 2013 at 11:06 PM, Michael MacFadden 
michael.macfad...@gmail.com wrote:

 Looks like there were some more votes on the other tool.

 On 7/24/13 1:25 PM, John Blossom jblos...@gmail.com wrote:

 Thanks, Michael, Ali, if you could please confirm that you'll be able
to
 attend, that would be great. Any concerns, please don't hesitate to
bring
 them up now, thanks.
 
 All the best,
 
 John Blossom
 
 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com/+JohnBlossom
 
 
 On Wed, Jul 24, 2013 at 1:49 PM, Joseph Gentle jose...@gmail.com
wrote:
 
  Great.
 
  I'd like to ask that everyone who attends has a basic understanding
of
  how wave's current OT algorithm works. There are several videos and
  blog posts on the subject. Here's a video of me explaining the same
  algorithm in the context of sharejs:
  http://www.youtube.com/watch?v=CsfiADbXTPo
  ... but there's many more resources kicking around.
 
  -J
 
  On Wed, Jul 24, 2013 at 3:48 AM, Bruno Gonzalez (aka stenyak)
  sten...@gmail.com wrote:
   I may be able to assist to the hangout too. I've submitted my
schedule
   to the doodle, but can't really guarantee I'll be there.
  
   On Tue, Jul 23, 2013 at 6:40 PM, John Blossom - Shore
Communications
   Inc. jblos...@shore.com wrote:
   Michael, as long as you, Ari and Joseph can make it, and the
 scheduling
   tool said that you can, I think that we'll have the core of the
  discussion.
   The objective is not to put on a show as much as it is to get the
 core
  OT
   thinkers driving the discussion. Let the ideas drive the interest.
  
   BTW, I shifted it up a half your, I have a telecon that starts at
 12.30.
   Consider this a kickoff event - let's shoot for somewhere south
of an
   hour's worth of very productive conversation and then let's start
  thinking
   about how to keep the conversations going at a very productive
level
 on
  a
   more regular basis. I am also totally for more impromptu efforts,
but
  for
   the sake of the community if we can post our conversations for
   community-wide access, that can help.
  
   Best Regards,
  
   John Blossom
   President
   Shore Communications Inc.
  
   where content, technology and people meet. (Salesmark of Shore
   Communications Inc.)
  
   web: shore.com
   blog: contentblogger.com
   email: jblos...@shore.com
   phone: 203.293.8511
   fax: 203.663.8259
   twitter: jblossom https://twitter.com/jblossom
   google+: google.com/+JohnBlossom
   LinkedIn: John Blossom http://www.linkedin.com/in/johnblossom
   facebook: John Blossom
   skype: jblossom
  
  
  
   On Tue, Jul 23, 2013 at 12:01 PM, Michael MacFadden 
   michael.macfad...@gmail.com wrote:
  
   John,
  
   Again I don't mean to delay the effort. But looking at the
attendee
   responses, I only see one person on the list that has agreed to
 attend
  that
   has really been heavily working OT issues in the last year or so
  (Joseph).
   So I am not sure what the objectives or the outcome of the
meeting
  will be
   with such low participation from OT experts.
  
   By no means do I mean to diminish any one else's capabilities,
but
 if
  the
   intention is to really dig in to OT, then I think we night need
  additional
   participation to be successful.
  
   ~Michael
  
   On Jul 23, 2013, at 8:40 AM, John Blossom - Shore Communications
  Inc. 
   jblos...@shore.com wrote:
  
I agree wholeheartedly that the entire Apache Wave community
 should
  be
excited about participating, and I assume that everyone on the
 list
  is
seeing this and should want to join in. If we have to
reschedule,
 no
biggie, we're at square zero and it's more about getting
people on
  board
and brainstorming. If you've been invited already, then invite
  others who
you think should be excited. To that end, here's the link to
the
  event:
   
https://plus.google.com/u/0/+JohnBlossom/posts/KTB6EkxB99q
   
If you're an Apache Wave committer and you miss the event, then
  you'll be
able to view it via YouTube via a link that I'll post here.
   
I do want to start accelerating communications more in the
  community, but
this is a busy week.
   
   
Best Regards,
   
John Blossom
President
Shore Communications Inc.
   
where content, technology and people meet. (Salesmark of Shore
Communications Inc.)
   
web: shore.com
blog: contentblogger.com
email: jblos...@shore.com
phone: 203.293.8511
fax: 203.663.8259
twitter: jblossom https://twitter.com/jblossom
google+: google.com/+JohnBlossom
LinkedIn

Re: Reminder: it should happen on-list (regarding upcoming Google Hangout)

[Michael MacFadden]

I am on board with this 100%.  We just always need to temper that by
making sure there is still visibility on these lists, as mentioned.

I would be willing to install a wave server at work that should be
persistent (always on).

On 7/25/13 7:00 PM, John Blossom jblos...@gmail.com wrote:

Yes, Joseph, the goal is to use the disciplines of Apache open source
development to build a platform that will rock the world. The disciplines
are important, but a sustainable, maintainable platform is the real goal
that the disciplines facilitate.

All the best,

John Blossom

email: jblos...@gmail.com
phone: 203.293.8511
google+: https://google.com/+JohnBlossom


On Thu, Jul 25, 2013 at 6:50 PM, Joseph Gentle jose...@gmail.com wrote:

 To be clear, our principle aim is to make a wave platform. Dogfooding
 our own software is only a major step if we call it one - I don't
 think we should move discussion there *yet*, but thats an obvious
 goal. Git isn't hosted in a subversion repository after all.

 -J


 On Thu, Jul 25, 2013 at 1:46 AM, Upayavira u...@odoko.co.uk wrote:
  Just a small thought to consider during this discussion.
 
  You are talking about some major changes to the tooling and workflow
  typical of Apache communities. Wave is currently in the incubator,
  making it a probationary project.
 
  I would say that the principal aim should be to understand the
  principles of the ASF, to demonstrate that understanding, and graduate
  from the incubator.
 
  Having done that, life will be easier when attempting such things as
  getting Wave enabled servers, engaging in PR, etc.
 
  Remember that graduation is based upon how the community operates, and
  has nothing to do with the quality, or otherwise, of the code-base.
 
  And the next big thing is getting that release out - proving that we
  understand how to correctly license(etc) our code. (We didn't actually
  get to the point of releasing, did we??)
 
  Upayavira
 
  On Wed, Jul 24, 2013, at 12:47 PM, Alfredo Abambres wrote:
  @Christian: below are some small considerations of mine about WWers
and
  AW
 
  Disclosure: I'm a WWers member and I'm speaking as myself solely, not
 for
  the network/organization WWer.org.
 
  On Wed, Jul 24, 2013 at 11:35 AM, Christian Grobmeier
  grobme...@gmail.comwrote:
 
   I like WW being an independent community which creates buzz
running by
   its own rules.
  
 
  At this moment, as I see it, *independent* is the keyword on all
this
  conversation.
 
 
  
   BTW, there is always the possibility to bring the WW community to
the
   ASF too. Given
   the tools WW is using, it doesn't make sense at the moment. Maybe
 later
   when AW
   is stable and installed at ASF it makes sense to include the WW
 community
   as
   part of the AW community. Something similar happened with Apache
   OpenOffice.
   People were running a support forum for OpenOffice and they have
   joined the project.
  
 
  Thanks for your suggestions, it's great to see that our work matter
and
  that we can still add lots of value to the future of Wave and Apache
  Wave.
 
  I *personally* don't see WWer.org ever becoming a AW community (but
  things
  change, right?!). That doesn't mean, that the community (people) that
 now
  represent WWer.org can't form other communities, even within AW. IMO,
  WWers
  members are probably the best prepared ones to assume that role and
make
  it
  happen, on a similar approach to your example about Apache OpenOffice
  support forum.
 
  It's great to know that those doors exist and may be open when
needed.
  Once again thanks.

Re: Delving into OT

[Michael MacFadden]

Looks like there were some more votes on the other tool.

On 7/24/13 1:25 PM, John Blossom jblos...@gmail.com wrote:

Thanks, Michael, Ali, if you could please confirm that you'll be able to
attend, that would be great. Any concerns, please don't hesitate to bring
them up now, thanks.

All the best,

John Blossom

email: jblos...@gmail.com
phone: 203.293.8511
google+: https://google.com/+JohnBlossom


On Wed, Jul 24, 2013 at 1:49 PM, Joseph Gentle jose...@gmail.com wrote:

 Great.

 I'd like to ask that everyone who attends has a basic understanding of
 how wave's current OT algorithm works. There are several videos and
 blog posts on the subject. Here's a video of me explaining the same
 algorithm in the context of sharejs:
 http://www.youtube.com/watch?v=CsfiADbXTPo
 ... but there's many more resources kicking around.

 -J

 On Wed, Jul 24, 2013 at 3:48 AM, Bruno Gonzalez (aka stenyak)
 sten...@gmail.com wrote:
  I may be able to assist to the hangout too. I've submitted my schedule
  to the doodle, but can't really guarantee I'll be there.
 
  On Tue, Jul 23, 2013 at 6:40 PM, John Blossom - Shore Communications
  Inc. jblos...@shore.com wrote:
  Michael, as long as you, Ari and Joseph can make it, and the
scheduling
  tool said that you can, I think that we'll have the core of the
 discussion.
  The objective is not to put on a show as much as it is to get the
core
 OT
  thinkers driving the discussion. Let the ideas drive the interest.
 
  BTW, I shifted it up a half your, I have a telecon that starts at
12.30.
  Consider this a kickoff event - let's shoot for somewhere south of an
  hour's worth of very productive conversation and then let's start
 thinking
  about how to keep the conversations going at a very productive level
on
 a
  more regular basis. I am also totally for more impromptu efforts, but
 for
  the sake of the community if we can post our conversations for
  community-wide access, that can help.
 
  Best Regards,
 
  John Blossom
  President
  Shore Communications Inc.
 
  where content, technology and people meet. (Salesmark of Shore
  Communications Inc.)
 
  web: shore.com
  blog: contentblogger.com
  email: jblos...@shore.com
  phone: 203.293.8511
  fax: 203.663.8259
  twitter: jblossom https://twitter.com/jblossom
  google+: google.com/+JohnBlossom
  LinkedIn: John Blossom http://www.linkedin.com/in/johnblossom
  facebook: John Blossom
  skype: jblossom
 
 
 
  On Tue, Jul 23, 2013 at 12:01 PM, Michael MacFadden 
  michael.macfad...@gmail.com wrote:
 
  John,
 
  Again I don't mean to delay the effort. But looking at the attendee
  responses, I only see one person on the list that has agreed to
attend
 that
  has really been heavily working OT issues in the last year or so
 (Joseph).
  So I am not sure what the objectives or the outcome of the meeting
 will be
  with such low participation from OT experts.
 
  By no means do I mean to diminish any one else's capabilities, but
if
 the
  intention is to really dig in to OT, then I think we night need
 additional
  participation to be successful.
 
  ~Michael
 
  On Jul 23, 2013, at 8:40 AM, John Blossom - Shore Communications
 Inc. 
  jblos...@shore.com wrote:
 
   I agree wholeheartedly that the entire Apache Wave community
should
 be
   excited about participating, and I assume that everyone on the
list
 is
   seeing this and should want to join in. If we have to reschedule,
no
   biggie, we're at square zero and it's more about getting people on
 board
   and brainstorming. If you've been invited already, then invite
 others who
   you think should be excited. To that end, here's the link to the
 event:
  
   https://plus.google.com/u/0/+JohnBlossom/posts/KTB6EkxB99q
  
   If you're an Apache Wave committer and you miss the event, then
 you'll be
   able to view it via YouTube via a link that I'll post here.
  
   I do want to start accelerating communications more in the
 community, but
   this is a busy week.
  
  
   Best Regards,
  
   John Blossom
   President
   Shore Communications Inc.
  
   where content, technology and people meet. (Salesmark of Shore
   Communications Inc.)
  
   web: shore.com
   blog: contentblogger.com
   email: jblos...@shore.com
   phone: 203.293.8511
   fax: 203.663.8259
   twitter: jblossom https://twitter.com/jblossom
   google+: google.com/+JohnBlossom
   LinkedIn: John Blossom http://www.linkedin.com/in/johnblossom
   facebook: John Blossom
   skype: jblossom
  
  
  
   On Tue, Jul 23, 2013 at 10:16 AM, Michael MacFadden 
   michael.macfad...@gmail.com wrote:
  
   I don't want to delay this thing, but are there really no other
 people
  who
   are interested in this?  I think we should really try to reach
out
   personally to some other folks to see if we can attract them in.
  
   ~Michael
  
   On 7/23/13 7:00 AM, John Blossom jblos...@gmail.com wrote:
  
   1200 ET, btw - bad math.
  
   All the best,
  
   John Blossom
  
   email: jblos...@gmail.com
   phone: 203.293.8511
   google

Re: Delving into OT

[Michael MacFadden]

I don't want to delay this thing, but are there really no other people who
are interested in this?  I think we should really try to reach out
personally to some other folks to see if we can attract them in.

~Michael

On 7/23/13 7:00 AM, John Blossom jblos...@gmail.com wrote:

1200 ET, btw - bad math.

All the best,

John Blossom

email: jblos...@gmail.com
phone: 203.293.8511
google+: https://google.com/+JohnBlossom


On Tue, Jul 23, 2013 at 9:53 AM, John Blossom jblos...@gmail.com wrote:

 OK, the consensus time/date for the hangout seems to be Wednesday, 31
 July, 1600 UTC (1000 EDT). I will create and event later today in
Hangouts.
 If you're on the wave-dev list and have a Google login, please forward
me
 your email ID/Google+ ID privately and I will add you to the circle of
 invitees. I Have Joseph's ID already and I believe Ali and Michael also,
 but if you have a doubt, just send it along. If you don't make the
hangout
 itself, I will be sure to share the link here for the common record.

 All the best,

 John Blossom

 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com/+JohnBlossom


 On Thu, Jul 18, 2013 at 9:06 AM, John Blossom jblos...@gmail.com
wrote:

 Ali,

 New tool for me, but worth a try. Here's the Doodle link:
 http://doodle.com/5z7usamgh7kee4gf

 I am open to other times, but these seem to be the most logical. Please
 remember that UTC at this time of year is one hour less ahead from the
U.S.
 time zones due to Daylight Savings Time - e.g., ET is UTC+4 right now.

 All the best,

 John Blossom

 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com/+JohnBlossom


 On Wed, Jul 17, 2013 at 5:57 PM, Ali Lown a...@lown.me.uk wrote:

 I agree that another hangout sounds fun.

 John, how about setting up a Doodle for us to mark some dates on?
 (http://doodle.com/)

 Ali

 On 17 July 2013 15:33, John Blossom jblos...@gmail.com wrote:
  Great, Michael, find a date that works for you that seems to match
with
  others' interests and I will be glad to arrange for this. We can
have
 the
  link available but not make public, if that helps to encourage
 constructive
  participation.
 
  All the best,
 
  John Blossom
 
  email: jblos...@gmail.com
  phone: 203.293.8511
  google+: https://google.com/+JohnBlossom
 
 
  On Wed, Jul 17, 2013 at 10:30 AM, Michael MacFadden 
  michael.macfad...@gmail.com wrote:
 
  I am definitely interested.  I will check my schedule for next
week.
 
  ~Michael
 
  On 7/16/13 11:02 AM, John Blossom jblos...@gmail.com wrote:
 
  That was my thought, also. ApacheWavers, please respond with some
 avails
  calibrated to UT+1 for this week and next week. Time to get this
 party
  started! My L,A. project is waiting for the funder to come
through,
 but my
  Nkommo project is gaining steam - hopeful that we'll have some
 exciting
  announcements fairly soon. Time to change the world with Wave!!!
  
  All the best,
  
  John Blossom
  
  email: jblos...@gmail.com
  phone: 203.293.8511
  google+: https://google.com/+JohnBlossom
  
  
  On Tue, Jul 16, 2013 at 1:58 PM, Joseph Gentle jose...@gmail.com
 wrote:
  
   I've had a busy few weeks - gearing up to launch our product at
 work.
   We should organize another hangout sometime.
  
   -J
  
   On Sat, Jul 13, 2013 at 7:24 AM, John Blossom - Shore
 Communications
   Inc. jblos...@shore.com wrote:
Soo...how is this initiative going? How may I help to move it
 forward?
   
Best Regards,
   
John Blossom
President
Shore Communications Inc.
   
where content, technology and people meet. (Salesmark of Shore
Communications Inc.)
   
web: shore.com
blog: contentblogger.com
email: jblos...@shore.com
phone: 203.293.8511
fax: 203.663.8259
twitter: jblossom https://twitter.com/jblossom
google+: google.com/+JohnBlossom
LinkedIn: John Blossom
http://www.linkedin.com/in/johnblossom
facebook: John Blossom
skype: jblossom
   
   
   
On Mon, Jul 8, 2013 at 9:43 AM, John Blossom
jblos...@gmail.com
 
  wrote:
   
Ingenious, Torben, certainly adds efficiency. John
   
On Mon, Jul 1, 2013 at 4:38 AM, Torben Weis 
 torben.w...@gmail.com
   wrote:
   
2013/6/25 Joseph Gentle jose...@gmail.com
   

  When peers connect, they send each other missing ops.
 Figuring
  out
  which ops are missing can be surprisingly tricky - but
 we'll
   figure
  that out later. New ops must be ingested in order, so
we
 always
ingest
  an operation after ingesting all of its parents.

 Just use a Merkle Tree that is at the same time a prefix
 tree with
respect
to the hashes of the ops (explanation below).
The bandwidth usage is O(1) if both clients are in sync and
 O(log
  n) if
they have one or few different ops and O(n) in the worst
case,
  where n
   in
the number of ops.
   
Constructing the tree is simple.
Let the hash function output 20 bytes and let's encode this
in
 hex

Re: Delving into OT

[Michael MacFadden]

John,

Again I don't mean to delay the effort. But looking at the attendee responses, 
I only see one person on the list that has agreed to attend that has really 
been heavily working OT issues in the last year or so (Joseph). So I am not 
sure what the objectives or the outcome of the meeting will be with such low 
participation from OT experts. 

By no means do I mean to diminish any one else's capabilities, but if the 
intention is to really dig in to OT, then I think we night need additional 
participation to be successful.  

~Michael

On Jul 23, 2013, at 8:40 AM, John Blossom - Shore Communications Inc. 
jblos...@shore.com wrote:

 I agree wholeheartedly that the entire Apache Wave community should be
 excited about participating, and I assume that everyone on the list is
 seeing this and should want to join in. If we have to reschedule, no
 biggie, we're at square zero and it's more about getting people on board
 and brainstorming. If you've been invited already, then invite others who
 you think should be excited. To that end, here's the link to the event:
 
 https://plus.google.com/u/0/+JohnBlossom/posts/KTB6EkxB99q
 
 If you're an Apache Wave committer and you miss the event, then you'll be
 able to view it via YouTube via a link that I'll post here.
 
 I do want to start accelerating communications more in the community, but
 this is a busy week.
 
 
 Best Regards,
 
 John Blossom
 President
 Shore Communications Inc.
 
 where content, technology and people meet. (Salesmark of Shore
 Communications Inc.)
 
 web: shore.com
 blog: contentblogger.com
 email: jblos...@shore.com
 phone: 203.293.8511
 fax: 203.663.8259
 twitter: jblossom https://twitter.com/jblossom
 google+: google.com/+JohnBlossom
 LinkedIn: John Blossom http://www.linkedin.com/in/johnblossom
 facebook: John Blossom
 skype: jblossom
 
 
 
 On Tue, Jul 23, 2013 at 10:16 AM, Michael MacFadden 
 michael.macfad...@gmail.com wrote:
 
 I don't want to delay this thing, but are there really no other people who
 are interested in this?  I think we should really try to reach out
 personally to some other folks to see if we can attract them in.
 
 ~Michael
 
 On 7/23/13 7:00 AM, John Blossom jblos...@gmail.com wrote:
 
 1200 ET, btw - bad math.
 
 All the best,
 
 John Blossom
 
 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com/+JohnBlossom
 
 
 On Tue, Jul 23, 2013 at 9:53 AM, John Blossom jblos...@gmail.com wrote:
 
 OK, the consensus time/date for the hangout seems to be Wednesday, 31
 July, 1600 UTC (1000 EDT). I will create and event later today in
 Hangouts.
 If you're on the wave-dev list and have a Google login, please forward
 me
 your email ID/Google+ ID privately and I will add you to the circle of
 invitees. I Have Joseph's ID already and I believe Ali and Michael also,
 but if you have a doubt, just send it along. If you don't make the
 hangout
 itself, I will be sure to share the link here for the common record.
 
 All the best,
 
 John Blossom
 
 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com/+JohnBlossom
 
 
 On Thu, Jul 18, 2013 at 9:06 AM, John Blossom jblos...@gmail.com
 wrote:
 
 Ali,
 
 New tool for me, but worth a try. Here's the Doodle link:
 http://doodle.com/5z7usamgh7kee4gf
 
 I am open to other times, but these seem to be the most logical. Please
 remember that UTC at this time of year is one hour less ahead from the
 U.S.
 time zones due to Daylight Savings Time - e.g., ET is UTC+4 right now.
 
 All the best,
 
 John Blossom
 
 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com/+JohnBlossom
 
 
 On Wed, Jul 17, 2013 at 5:57 PM, Ali Lown a...@lown.me.uk wrote:
 
 I agree that another hangout sounds fun.
 
 John, how about setting up a Doodle for us to mark some dates on?
 (http://doodle.com/)
 
 Ali
 
 On 17 July 2013 15:33, John Blossom jblos...@gmail.com wrote:
 Great, Michael, find a date that works for you that seems to match
 with
 others' interests and I will be glad to arrange for this. We can
 have
 the
 link available but not make public, if that helps to encourage
 constructive
 participation.
 
 All the best,
 
 John Blossom
 
 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com/+JohnBlossom
 
 
 On Wed, Jul 17, 2013 at 10:30 AM, Michael MacFadden 
 michael.macfad...@gmail.com wrote:
 
 I am definitely interested.  I will check my schedule for next
 week.
 
 ~Michael
 
 On 7/16/13 11:02 AM, John Blossom jblos...@gmail.com wrote:
 
 That was my thought, also. ApacheWavers, please respond with some
 avails
 calibrated to UT+1 for this week and next week. Time to get this
 party
 started! My L,A. project is waiting for the funder to come
 through,
 but my
 Nkommo project is gaining steam - hopeful that we'll have some
 exciting
 announcements fairly soon. Time to change the world with Wave!!!
 
 All the best,
 
 John Blossom
 
 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com

Re: Delving into OT

[Michael MacFadden]

I am definitely interested.  I will check my schedule for next week.

~Michael

On 7/16/13 11:02 AM, John Blossom jblos...@gmail.com wrote:

That was my thought, also. ApacheWavers, please respond with some avails
calibrated to UT+1 for this week and next week. Time to get this party
started! My L,A. project is waiting for the funder to come through, but my
Nkommo project is gaining steam - hopeful that we'll have some exciting
announcements fairly soon. Time to change the world with Wave!!!

All the best,

John Blossom

email: jblos...@gmail.com
phone: 203.293.8511
google+: https://google.com/+JohnBlossom


On Tue, Jul 16, 2013 at 1:58 PM, Joseph Gentle jose...@gmail.com wrote:

 I've had a busy few weeks - gearing up to launch our product at work.
 We should organize another hangout sometime.

 -J

 On Sat, Jul 13, 2013 at 7:24 AM, John Blossom - Shore Communications
 Inc. jblos...@shore.com wrote:
  Soo...how is this initiative going? How may I help to move it forward?
 
  Best Regards,
 
  John Blossom
  President
  Shore Communications Inc.
 
  where content, technology and people meet. (Salesmark of Shore
  Communications Inc.)
 
  web: shore.com
  blog: contentblogger.com
  email: jblos...@shore.com
  phone: 203.293.8511
  fax: 203.663.8259
  twitter: jblossom https://twitter.com/jblossom
  google+: google.com/+JohnBlossom
  LinkedIn: John Blossom http://www.linkedin.com/in/johnblossom
  facebook: John Blossom
  skype: jblossom
 
 
 
  On Mon, Jul 8, 2013 at 9:43 AM, John Blossom jblos...@gmail.com
wrote:
 
  Ingenious, Torben, certainly adds efficiency. John
 
  On Mon, Jul 1, 2013 at 4:38 AM, Torben Weis torben.w...@gmail.com
 wrote:
 
  2013/6/25 Joseph Gentle jose...@gmail.com
 
  
When peers connect, they send each other missing ops. Figuring
out
which ops are missing can be surprisingly tricky - but we'll
 figure
that out later. New ops must be ingested in order, so we always
  ingest
an operation after ingesting all of its parents.
  
   Just use a Merkle Tree that is at the same time a prefix tree with
  respect
  to the hashes of the ops (explanation below).
  The bandwidth usage is O(1) if both clients are in sync and O(log
n) if
  they have one or few different ops and O(n) in the worst case,
where n
 in
  the number of ops.
 
  Constructing the tree is simple.
  Let the hash function output 20 bytes and let's encode this in hex.
 This
  results in a hash-string of 40 hex-characters for each operation.
  Each node hashes over the hashes of its children. Leaf-nodes
 correspond to
  operations and thus use the hash value of their respective
operation.
  The tree-invariant is that all siblings on level x share the same
 prefix
  of
  x hex-characters.
  The tree is not sent over the network. Instead, clients start
comparing
  the
  hashes at the root.
 
  Two clients compare their root hash. If it is equal, the entire
tree is
  equal and therefore they are in sync.
  If not, they download all direct children and repeat the procedure
for
  each
  sub-tree rooted by one of these children.
  For example, if child number 3 has a different hash, but all others
 share
  the same hash, then we have learned that there are one or more ops
 with a
  hash of 3... that are different and need syncing.
 
  Typically we can limit the depth of the tree to few levels. 8 levels
  already yield a tree that could store 16^8 possible ops. So in the
 worst
  case two clients need to wait for 8 round-trips to determine a
missing
 op.
 
  In addition, each client sends a time stamp. So when syncing we
report
 the
  last time stamp received from this client and ask for all ops this
 client
  received later. If these are few, then simply get them (even if we
know
  some of the ops already, because we got them from another client).
If
  there
  are too many ops, fall back to the merkle tree. With a good
 approximation
  of RTT and bandwidth, it is easy to calculate which algorithm is the
 best
  to sync two clients.
 
  Greetings
  Torben
 
 
 

Re: A New Committer

[Michael MacFadden]

My two cents on the protocol site would be that we should create a section
on the apache site and/or wiki dedicated to protocols.  The
waveprotocol.org domain could point to that.

On 7/8/13 7:53 AM, John Blossom jblos...@gmail.com wrote:

Ali,
Thanks so much, thoughts below. Best, John

On Mon, Jul 8, 2013 at 10:28 AM, Ali Lown a...@lown.me.uk wrote:

 Heh. This saves us having to write an [ANNOUNCE] for you...

FIRST! Tee hee.


  One key thing that I'd like to chip away at is getting our Web
presences
  sussed out a bit more. Web sites/ownership, social media presences,
  communications with the media - all of these need to get organized for
  success.

 I am not sure what sort of 'social media presence' would make sense
 for an Apache project? Could you clarify?

One of the challenges that many products/platforms have is awareness of a
given presence as a brand. When people say Apache Wave in places like
Facebook or Google+ or Twitter, for example, we want people to catch on
that Apache Wave communicates about itself via social media to developers
and to the public via more than just its own Web site. So it would make
sense to have for official announcements and general communications a
Facebook page, a Google+ page, a Twitter account and perhaps a LinkedIn
account. This is important for people referencing us in their posts as
well
as for our own communications. So, for example, when I write a post in
Google+ that references Apache Wave, a +Apache Wave link will provide
a
hyperlink in that post to an Apache Wave page on Google+, which can have
announcements and links to our official site.  These are fundamental and
important marketing tools, IMO, and can enable us to publicise key
milestones and services availability more effectively.



  Example: shouldn't waveprotocol.org be labeled clearly as an
  Apache Wave asset?

 The wave protocol site is controlled by Michael (IIRC), and is was not
 originally directly related to the Apache project, rather the
 open-source protocol behind wave. (Of which we seem to have become the
 keepers).

 We have had several attempts in the past to migrate the useful
 information over to the wiki here, which I think is now complete.
 (If anybody knows any relevant, up-to-date information left on
 waveprotocol.org that is not on the wiki here, please add it!)
 As such, I don't know if there is any point in keeping
 waveprotocol.org any more? (Perhaps it should just redirect to our
 incubator site?)


I am thinking that a redirect would be the right thing to do if all of the
information is migrated, presuming that we have control of the DNS record
to do this. We need to make the Apache ownership of the brand 100 percent
clear.


 Ali

Re: John's Wiki Permissions

[Michael MacFadden]

I'll update the permissions. 

~Michael

On Jun 28, 2013, at 12:06 AM, Upayavira u...@odoko.co.uk wrote:

 Christian didn't say exclusive, only that for PPMC members it is given
 without question.
 
 I'm very happy for you to help out.
 
 Upayavira
 
 On Fri, Jun 28, 2013, at 08:01 AM, Angus Turner wrote:
 I'm not a PMC but I could just see that as a way to further help out.
 Nevermind :)
 
 Thanks
 Angus Turner
 angusisf...@gmail.com
 
 
 On Fri, Jun 28, 2013 at 4:43 PM, Christian Grobmeier
 grobme...@gmail.comwrote:
 
 On Fri, Jun 28, 2013 at 3:19 AM, Angus Turner angusisf...@gmail.com
 wrote:
 Hey Michael,
 Wondering if its possible to give someone else admin to the wiki so
 you don't have to do it all the time...
 
 Every PMC member should have Admin-Wiki access on request
 
 Cheers
 
 
 
 
 On 6/28/13, Michael MacFadden michael.macfad...@gmail.com wrote:
 John,
 
 I have given you wiki permissions!
 
 ~Michael
 
 
 --
 Thanks
 Angus Turner
 angusisf...@gmail.com
 
 
 
 --
 http://www.grobmeier.de
 https://www.timeandbill.de
 

John's Wiki Permissions

[Michael MacFadden]

John,

I have given you wiki permissions!

~Michael

Re: Joining as a Mentor

[Michael MacFadden]

John,

If you have a username on confluence, then I can give you permissions.

~Michael

On 6/25/13 8:12 AM, John Blossom jblos...@gmail.com wrote:

Thank you! Glad to have your help.

BTW, how does one add oneself to be an editor of the wiki? Anyone? Thanks.
John Blossom

On Tue, Jun 25, 2013 at 5:01 AM, Christian Grobmeier
grobme...@gmail.comwrote:

 Thanks all!

 I have subscribed myself now

 On Sat, Jun 22, 2013 at 6:45 PM, John Blossom jblos...@gmail.com
wrote:
  I've appreciated your help and insight, glad to have you aboard. Best,
 John
 
  On Fri, Jun 21, 2013 at 12:19 PM, Christian Grobmeier
  grobme...@gmail.comwrote:
 
  Hello Wave'rs,
 
  as you might know, I am Apache Member and involved in various
  projects. I also have mentored a bunch of podlings, like for example
  OpenOffice, OGNL and Onami. Currently I am helping the Ripple
podling.
  You also have already seen in this list.
 
  Currently there is Upayavira who does a great job with mentoring.
With
  the new activity in this podling I would like to help him, because he
  is the only active mentor currently.
 
  Now I would like to ask the project if they would like to see me
  stepping up as a mentor.
 
  Basically I would do the things I currently do, but would also be
able
  to sign the reports. If there are no objections, I will notify the
  IPMC and update the mentors list for Wave.
 
  Cheers,
  Christian
 
  --
  http://www.grobmeier.de
  https://www.timeandbill.de
 



 --
 http://www.grobmeier.de
 https://www.timeandbill.de

Re: Delving into OT

[Michael MacFadden]

I will respond to this section by section in a bit. 

However my general comment is that there is a lot to digest here and I think we 
need to start putting this stuff in a wiki page(s). I think it will get buried 
here. I think we might need individual pages on each protocol idea. And the a 
pro/con page where we compare them based on discussions on the list. 

~Michael

On Jun 24, 2013, at 1:06 PM, Joseph Gentle jose...@gmail.com wrote:

 I want to start the discussion around what OT algorithms to use. This
 is going to get technical. This is not a bug. Please ask simple but
 tangential questions (like how does wave's current crypto system
 work?) in a new thread instead of this one.
 
 Requirements:
 - Arbitrary peers can syncronize data
 - We can collaboratively edit tree structures, key-value pairs and
 rich text. (I'd like arbitrary JSON editing)
 - Fast enough to work on mobile devices. Protocol needs to be low
 bandwidth and require a low number of network round-trips.
 - Ideally a low storage overhead
 
 Nice-to-have:
 - End-to-end encryption of content. (In the wake of PRISM, the less
 information my wave server needs to know about me, the better.)
 - Some wave version of OTR[1]
 - Presence  cursors
 - Simple. At least, as simple as we can manage. Lets at least try :/
 
 Is there anything else I'm missing? Some of this stuff is only
 tangentially related to OT (like cursors and encryption), but its
 still important we bring it up.
 
 
 Given that we want to be able to connect arbitrary peers, I think it
 makes sense to use a message encryption  signing system. Currently,
 wave servers sign their user's messages. To support users
 collaborating over a LAN without servers, we should allow users to
 sign ( encrypt) their own messages. Unfortunately, the signature will
 become invalid if the operation is transformed.
 
 Consider peers A and B (communicating over a LAN), and disconnected
 peer C. A and B each generate simultaneous operations and sign their
 operations. A sends its operation to B, who transforms it. B then
 connects to C and sends both operations. For C to verify A's
 operation, C must see the original (untransformed) version of the
 operation. I think the only way we can make this work securely is by
 only sending original operations instead of sending operations after
 they've been transformed.
 
 As far as I know, there's three broad directions we could take 
 algorithmically:
 1. CRDTs (like Logoot[1])
 2. 'Classical' OT using vector clocks for versioning.
 3. The OT system that Torben Weis was working on. (Some might remember
 him from the wave summit a few years ago). I have been chatting on and
 off with him about this since the summit. He hasn't published anything
 on it yet though. Its similar to classical OT, except using git style
 version hashes.
 
 
 CRDTs are probably the most elegant solution. They avoid the entire
 complicated mess of transformation. However:
 - They add a significant overhead to the document size (we must store
 a unique name between every two characters in the wave)
 - As far as I know, nobody has implemented arbitrary JSON editing
 using CRDTs. Implementing a set is very difficult.
 - Even without transform, we'll still have to store operations anyway
 so peers can verify signatures.
 
 I'd like to know what we should expect the actual document size
 overhead to be. I expect it to be at least a 5x size increase, but I
 don't know for sure. The papers I've read cleverly minimize the
 overhead by only doing OT on a line-by-line basis, but thats
 unacceptable for wave.
 
 
 As I understand it, vector clocks are the size of the number of unique
 peers which have ever connected to the network. (They contain an
 integer version number per peer on the wave). As I understand them, a
 vector clock must be stored in each operation - which to me always
 seemed unpalatable enough I didn't explore them further. Note that
 this is per *peer*, not per user. If we want full p2p, this is one per
 device which has ever edited a wave.
 
 There's probably some clever ways we could minimize that size. Off the
 top of my head:
 - Most operations are generated on the same site as their single
 parent. These operations only increment the local version number. We
 could special case this. I don't know how much better this would make
 the system - I suspect a lot.
 - If we want, we could build a hybrid system where most clients use a
 client-server protocol like the current system. Servers could then use
 vector clocks or whatever to confer amongst themselves. This way we
 only need one element in the clock per server. However, we lose most
 of the benefits of having a p2p OT system to begin with.
 
 
 Torben's system is the one I know the most about. I'm biased to think
 thats the right answer because I understand it better than the others.
 I just spent the last couple hours writing up how it works, but I'm
 going to run it by Torben before posting to this list.
 
 It 

Re: Delving into OT

[Michael MacFadden]

See comments inline.

On 6/24/13 1:06 PM, Joseph Gentle jose...@gmail.com wrote:

I want to start the discussion around what OT algorithms to use. This
is going to get technical. This is not a bug. Please ask simple but
tangential questions (like how does wave's current crypto system
work?) in a new thread instead of this one.

Requirements:
In general, I'll put sup a requirements page where we can collect these
ideas.

- Arbitrary peers can syncronize data
I agree with this in principle, however I think this may be to generic a
statement for wave. I think I would like to understand exactly what our
usage scenarios are.  Are we really aiming to have a document on my mobile
device that I share with you over bluetooth and we collaborate?  Is this a
requirement?  It may be, but I think the exact use cases that we target
may heavily impact tradeoffs we are willing to make. It's easy to say pure
P2P, but let's think about it.

- We can collaboratively edit tree structures, key-value pairs and
rich text. (I'd like arbitrary JSON editing)
I would extend this to Object Structures (which can be viewed as tree like)

- Fast enough to work on mobile devices. Protocol needs to be low
bandwidth and require a low number of network round-trips.
- Ideally a low storage overhead

Nice-to-have:
- End-to-end encryption of content. (In the wake of PRISM, the less
information my wave server needs to know about me, the better.)
- Some wave version of OTR[1]
- Presence  cursors
- Simple. At least, as simple as we can manage. Lets at least try :/

Is there anything else I'm missing? Some of this stuff is only
tangentially related to OT (like cursors and encryption), but its
still important we bring it up.


Given that we want to be able to connect arbitrary peers, I think it
makes sense to use a message encryption  signing system. Currently,
wave servers sign their user's messages. To support users
collaborating over a LAN without servers, we should allow users to
sign ( encrypt) their own messages. Unfortunately, the signature will
become invalid if the operation is transformed.
There is a paper on this I will try to find tonight.


Consider peers A and B (communicating over a LAN), and disconnected
peer C. A and B each generate simultaneous operations and sign their
operations. A sends its operation to B, who transforms it. B then
connects to C and sends both operations. For C to verify A's
operation, C must see the original (untransformed) version of the
operation. I think the only way we can make this work securely is by
only sending original operations instead of sending operations after
they've been transformed.

As far as I know, there's three broad directions we could take
algorithmically:
1. CRDTs (like Logoot[1])
For CRDT look at this paper (It's a little more recent.):
http://hal.inria.fr/docs/00/60/93/99/PDF/RR-7687.pdf



2. 'Classical' OT using vector clocks for versioning.
3. The OT system that Torben Weis was working on. (Some might remember
him from the wave summit a few years ago). I have been chatting on and
off with him about this since the summit. He hasn't published anything
on it yet though. Its similar to classical OT, except using git style
version hashes.


CRDTs are probably the most elegant solution. They avoid the entire
complicated mess of transformation. However:
- They add a significant overhead to the document size (we must store
a unique name between every two characters in the wave)
- As far as I know, nobody has implemented arbitrary JSON editing
using CRDTs. Implementing a set is very difficult.
- Even without transform, we'll still have to store operations anyway
so peers can verify signatures.

I'd like to know what we should expect the actual document size
overhead to be. I expect it to be at least a 5x size increase, but I
don't know for sure. The papers I've read cleverly minimize the
overhead by only doing OT on a line-by-line basis, but thats
unacceptable for wave.


As I understand it, vector clocks are the size of the number of unique
peers which have ever connected to the network.
Technically its only peers that have generated an operations, rather than
ones that have just connected.

 (They contain an
integer version number per peer on the wave). As I understand them, a
vector clock must be stored in each operation -
Yep.  Overhead.

which to me always
seemed unpalatable enough I didn't explore them further. Note that
this is per *peer*, not per user. If we want full p2p, this is one per
device which has ever edited a wave.

There's probably some clever ways we could minimize that size. Off the
top of my head:
- Most operations are generated on the same site as their single
parent. These operations only increment the local version number. We
could special case this. I don't know how much better this would make
the system - I suspect a lot.
- If we want, we could build a hybrid system where most clients use a
client-server protocol like the current system. Servers could then use

[DISCUSS] Apache Wave Sub Committees

[Michael MacFadden]

Wavers,

Apache is an open community and a do-ocracy. We don't have a hierarchical 
structure and anyone is welcome to contribute in any way they wish.  This is a 
key principle of being an Apache project.

At the same time we need to start to have focus in several key areas in order 
to progress. As such I am recommending we for sever committees with focused 
topics of discussion, specific goals, and plans of action. The committees are 
not intended to be exclusive in any manor. Discussion will happen on the dev 
list where everyone is welcome to participate. Rather the point of the 
committee is to give some focus to a group of developers who agree to help 
advance particular aspects of Apache Wave.  These members would commit to 
facilitating discussion on certain aspects of wave. 

I propose we form four committees based on my observation of the wave project. 

1. Operational Transformation
Research and design of OT algorithms, data models, and concurrency control.

2. Protocols
Investigate protocols such as federation, client server, and the underlying 
mechanisms such as protocol transport and discovery. 

3. Development, Build (eg maven) and Release
This committee would focus on making wave easier to develop, build, and 
release. This can include documentation, architecture diagrams, maven, git, 
etc. this will hopefully help attract developers to the project.

4. Client / Server Architecture
This last group would leverage the work of the first three to start to separate 
the client and server components.

The vision would be that the committees would start holding regular discussions 
and start to document plans and decisions in sections of the wiki. 

I would like your thoughts on the formation of committees, if we have the right 
ones identified, and if there is interest in supporting this model. 

Regards,

Michael MacFadden
http://www.macfadden.org

Re: [DISCUSS] Apache Wave Sub Committees

[Michael MacFadden]

Joseph,

I think I should make it clear that the committee has absolutely no
authority.  A committer does not have to check with a committee to commit
something or to make a change.  The committee gets no special voting
rights.  The only idea of the committee is to have 2-5 people who commit
to making sure we advance discussion on the mailing list, and then record
the major design decisions results in a wiki page.

Anyone can participate in the discussions.  And any one can contribute.
The committee is simply there to facilitate discussion on an important
topic and to make sure we make progress. Furthermore, committees can be
ephemeral.  Meaning if we have something that needs attention right now,
we can form a committee, then later when that has been resolved we can
dissolve the committee.  When a new topic arises we can form a new
committee.

The whole reason for doing this is that we have a lot of discussion going
on now in the list, but most of it wanders all over the place, and not
much actual decision making has happened. I think that forming a committee
that ensures we set objectives, have discussions, and make decisions in a
focused and timely manner will help.  But as I said in no way do these
people become gate keepers and people would not need permission from the
committee.  

They are just volunteers who agree to help move the conversation along.

Does this make more sense?

~Michael



On 6/23/13 4:54 PM, Joseph Gentle jose...@gmail.com wrote:

These are the steps I think we should take around the new federation
protocol:

1a. Figure out a p2p-capable OT algorithm  design that we're all
happy with. Make an in-process proof-of-implementation  randomizer to
convince myself its correct  not horrendously slow.

1b. Decide what data structure we want for waves. (See thread: 'A Very
Wavey Plan')

2. Implement (1) in a way that allows two processes to share a
document via OT. This will require figuring out a really simple
unauthenticated federation protocol. I expect to first get this
working for plaintext documents, then swap over to the wave data model
once we have decided on a data model and written transform (etc)
functions for it.

3. Decide what kind of encryption to use for operations  documents, if
any.

4. Either / both of:
- Port the new code  concepts to WIAB.
- Add encryption, access control and a database to the proof of
implementation written in step 2. (I want a second compatible
implementation of wave written in !java)


For OT, we need to deep dive on algorithms with people who are well
read  know our options. For that, it would make sense to have a
working group to define the problem  discuss solutions. But when it
comes to actually coding it, I don't actually want input from
non-contributors. If etting your permission will only slow us down.

I guess the advantage of forming groups around the other issues is
that it gives people autonomy around making decisions and changes.
However, I worry that if committee groups aren't made up of actual
contributors, they'll simply add another hoop for contributors to jump
through before making meaningful changes to the code. Eg, if Ali and
Yuri decided they didn't like GYP, they shouldn't need permission from
anyone to fix it. And I also don't want non-committers telling them
not to.

So I guess, I'm happy to form committees so long as their purpose is
to move the project forward, not simply make recommendations for other
people to implement.

-J

On Sun, Jun 23, 2013 at 3:24 PM, Michael MacFadden
michael.macfad...@gmail.com wrote:
 Wavers,

 Apache is an open community and a do-ocracy. We don't have a
hierarchical structure and anyone is welcome to contribute in any way
they wish.  This is a key principle of being an Apache project.

 At the same time we need to start to have focus in several key areas in
order to progress. As such I am recommending we for sever committees
with focused topics of discussion, specific goals, and plans of action.
The committees are not intended to be exclusive in any manor. Discussion
will happen on the dev list where everyone is welcome to participate.
Rather the point of the committee is to give some focus to a group of
developers who agree to help advance particular aspects of Apache Wave.
These members would commit to facilitating discussion on certain aspects
of wave.

 I propose we form four committees based on my observation of the wave
project.

 1. Operational Transformation
 Research and design of OT algorithms, data models, and concurrency
control.

 2. Protocols
 Investigate protocols such as federation, client server, and the
underlying mechanisms such as protocol transport and discovery.

 3. Development, Build (eg maven) and Release
 This committee would focus on making wave easier to develop, build, and
release. This can include documentation, architecture diagrams, maven,
git, etc. this will hopefully help attract developers to the project.

 4. Client / Server Architecture
 This last group

Re: Demo Server

[Michael MacFadden]

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 fle...@gmail.com wrote:

will it be possible to run multiple experiments on one server ? i doubt it
but just thought i would ask.

i would love to run a bleeding edge wave server since the one i already
run
doesnt get *that* much use.


On Fri, Jun 21, 2013 at 7:11 PM, Upayavira u...@odoko.co.uk wrote:

 When the time comes, I'm prepared to have the necessary conversations to
 see about a VM at Apache.

 Upayavira

 On Fri, Jun 21, 2013, at 11:38 PM, Michael MacFadden wrote:
  Yes the point would be to get federation up and running.  An
providing a
  place where we can deploy our new OT containers that will need to
  communicate in a distributed way.
 
  On 6/21/13 3:35 PM, Bruno Gonzalez (aka stenyak) sten...@gmail.com
  wrote:
 
  That sounds good.
  
  Would it be interesting to apply for a VM at apache for that? I was
  thinking on doing so if/when the email bot is finished... (so that
both
  email and wave discussions of the Apache Wave group can happen under
the
  umbrella of Apache)
  
  Also, are you planning on enabling federation in some of those
servers?
  
  
  Either way, thanks for the efforts.
  
  
  On Sat, Jun 22, 2013 at 12:20 AM, Michael MacFadden 
  michael.macfad...@gmail.com wrote:
  
   All,
  
   As soon as we have a release, I am going to put the stable release
on
  two
   servers.  One will be my personal server. Another one will be a
server
   hosted by my company.  I think we we have a couple environments up
and
   running it will help.
  
   Also, I may be able to set up some sandboxes where we can actually
  deploy
   some of our experiments when we start looking at P2P / Server /
Hybrid
  OT.
  
   ~Michael
  
  
  
  
  
  --
  Saludos,
   Bruno González
  
  ___
  Jabber: stenyak AT gmail.com
  http://www.stenyak.com
 
 

Re: IRC discussion on P2P waving

[Michael MacFadden]

We should create a section for these topics in the wiki in some sort of design 
space. 

~Michael

On Jun 21, 2013, at 6:06 AM, John Blossom jblos...@gmail.com wrote:

 Bruno,
 
 Thanks, this is an excellent summary. It helps me to get the gist of things
 more clearly.
 
 On the P2P latency, I don't think that it would be unacceptable to draw a
 line and say that P2P provides limited, non-guaranteed realtime OT or that
 it's not realtime OT and more of a syncing mode than a conversation mode.
 That would probably be sufficient for what needs to be done, especially
 since in some instances P2P-enabled Wave sessions may be using MESH
 networks for transport - a key factor in how a lot of experimental
 communications services are being deployed in developing nations (not just
 the Project Loon concept). In the MESH model, you're likely to have one
 node within range of another temporarily, which may sync with it, and then
 pass along data to another node when it comes in range of it. That's the
 most probable scenario for P2P in many instances, I would think. The other
 potential scenario: two people in a remote location, for the sake of
 argument two movie script-writers who have holed themselves up in a remote
 location to collaborate on a common script. They're on two devices that are
 very proximate to one another, so perhaps the latency issues will not be so
 severe.
 
 Things to think about, I will look at this more carefully later today.
 
 All the best,
 
 John Blossom
 
 On Fri, Jun 21, 2013 at 8:05 AM, Bruno Gonzalez (aka stenyak) 
 sten...@gmail.com wrote:
 
 Following Joseph's A Very Wavey Plan (P2P!) thread, a couple of
 discussions have taken place at the irc.freenode.net #wiab channel, all
 related to P2P.
 
 I've taken the liberty to restructure the IRC logs, remove some chitchat,
 and divide it into sub-discussions. Feel free to reply to any part of this
 email to continue a discussion.
 
 
 *Summary of discussions:*
 **
 *1) Underlying protocol for P2P federation*
 Currently XMPP is used. HTTP and raw TCP are two suggested candidates (HTTP
 allowing to much more easily reach restricted networks).
 
 *2) Message/event types needed for P2P federation to work*
 We'd need something similar in concept to certain git operations (git
 clone, git push...). All will be based on hashes (not incremental
 integers).
 
 *3) Routing p2p messages/events in a server-aided network*
 One option is to somehow detect server clusters, send data to one of them,
 and let the rest of the cluster servers synchronize to it (locally).
 Alternatively, the originator server can naively send stuff to all possible
 destination servers, regardless of the cost.
 
 *4) Routing p2p messages/events in a pure P2P system (5 parts)*
 How to manage to route all wave-stuff if we want to completely get rid of
 servers completely, and only use peers.
 The closest way would be to use a DHT, but huge latency is an unsolved
 problem, and makes it impossible to use for real-time waving.
 No other solution has been proposed.
 
 *5) Implementing undo: invertibility, tombstones, edge cases, TP2*
 No server means no canonical order of commits, which means that undo is
 hard to do correctly.
 (uhm... not sure if that's a good summary, some stuff went over my head
 :-D, please read the log instead)
 
 *6) Usability of a pure p2p system in Real Life (tm)*
 Being pragmatic, pure P2P is probably only usable in peers with good
 connectivity. Rest of peers will need to rely on a server/proxy that *does*
 have good connectivity.
 
 *7) Comparison with BitTorrent and P2P-TV technologies*
 Both technologies are much less restricted than wave with regards to
 real-time responsiveness. So none are really a good reference for our
 purposes.
 
 *8) Identifying participants (3 parts)*
 Pure p2p means many peers don't have a n...@centralized-server.com user
 handle, so an alternative has to be used.
 However, it's easy to provide a traditional friendly handle, if the user
 prefers the tradeoff of having to often rely on a permanent server. This
 tradeoff can be mitigated by using a sort of userhandle cache.
 
 *9) P2P anonymity (lurking in a wave) (2 parts)*
 In a pure p2p wave network, anonymous peers may want to read a public wave,
 without other peers knowing. A solution could be to make private the
 required wavelets (where the anonymous participants IDs are stored).
 
 *10) Encryption of waves*
 It's been proposed to use an AES key to encrypt all the wave data, and only
 allow participants to decrypt it.
 
 *11) Addition and removal of participants, and their ability to read past
 and future wave versions/deltas*
 The aforementioned AES key can change over time, allowing a finer-grained
 restriction of what deltas new/removed participants can read.
 
 
 *
 *
 
 *Actual conversations:*
 **
 *
 *
 *1) Underlying protocol for P2P federation:*
 [in response to Joseph's email]
 [23:42] alown I [...] agree with option 

Re: Feedback from Incubator Vote

[Michael MacFadden]

True,

I would hate to see us inject ivy if we know we are going to just switch
to maven.

~Michael

On 6/21/13 4:34 AM, Christian Grobmeier grobme...@gmail.com wrote:

If I remember correctly, there is a maven transition nearly completed.
Ivy is a good option, but if maven is already done, why not use that?

On Fri, Jun 21, 2013 at 12:25 PM, Upayavira u...@odoko.co.uk wrote:
 Or use Ivy to download from the Maven repo.

 Upayavira

 On Fri, Jun 21, 2013, at 11:01 AM, Bruno Gonzalez (aka stenyak) wrote:
 Presumably we want wiab to be independent from third party download
 websites, so the get-third-party-libs script should point to our own
 mirror of all those jars?


 On Fri, Jun 21, 2013 at 11:58 AM, Angus Turner
 angusisf...@gmail.comwrote:

  +1 to adding all the third party .jars to an ant task. There's a
tonne of
  them in there, and it's hard to keep track of what licence what
library is
  under.
 
  Thanks
  Angus Turner
  angusisf...@gmail.com
 
 
  On Fri, Jun 21, 2013 at 7:27 PM, Upayavira u...@odoko.co.uk wrote:
 
  
  
   On Fri, Jun 21, 2013, at 10:14 AM, Ali Lown wrote:
It looks like RC3 will fail at the Incubator vote. (This is both
fine
and expected)
  
   Yep.
  
This also conveniently lets us merge some of the other fixes (for
example the broken translations/eclipse) in for RC4.
  
   Okay, but don't absorb *too* many changes.
  
The main problem seems to (still) be the third_party/* files
(particularly in the source release - I don't know if they are
okay to
be included in the 'binary' release).
  
   A *source* release must be source only. Third party jars aren't
source,
   so shouldn't be included. They are fine in a binary release.
  
It looks like the easiest way to handle this is to have them all
downloaded during the get-third-party ant task.
  
   That would be a reasonable thing for the build script in the src
   distribution to do, but so long as there is some way (even manual)
for
   that to happen, I don't see it as an issue.
  
Some comments were raised about the src/python/api files not
being
correctly licensed. Manually inspecting them it appears rat
wasn't
complaining because they are all Apache licensed, but we have
'Licensed under the Apache License' used for some, and (the
correct?)
'Licensed to the Apache Software Foundation' in others.
  
   The first would be valid for code written elsewhere, and the
latter for
   code being maintained here. Which are they?
  
We (may) need to file for an ECCN given we use bouncy-castle.
(Is this
only an issue if we include it, if we have it fetched by a
separate
task (given the IPMC don't seem to like having the jars shipped
with
Wave) is it still a problem?)
  
   The ECCN stuff is for 'exporting encryption'. If we release a
   convenience binary, then as far as the US govt is concerned, we
need to
   do the ECCN stuff.
  
   Upayavira
  
 



 --
 Saludos,
  Bruno González

 ___
 Jabber: stenyak AT gmail.com
 http://www.stenyak.com



--
http://www.grobmeier.de
https://www.timeandbill.de

Re: IRC discussion on P2P waving

[Michael MacFadden]

As for one small comment, yes UNDO must be implemented in OT if you have 
multiple participants. One simple example would be three users. Lets say an 
operation to insert a character goes from user A to user B it has not made it 
to user C. The user B decides to Undo. At that point the undo operation goes 
from user B to user A and user C. Now the problem is the undo action from B may 
arrive at C before the original operation from A arrived at C.

This would cause a problem without OT. 

~Michael

On Jun 21, 2013, at 6:49 AM, Pratik Paranjape pratikparanj...@gmail.com wrote:

 Awesome Bruno! Thanks for this.
 
 Good to see we are not totally ignoring networking, that would have been
 naive, it will be Elephant in the room.
 
 Good discussion there, will have to think over all points in detail, but on
 first pass:
 
 *Summary of discussions:*
 **
 *1) Underlying protocol for P2P federation*
 Currently XMPP is used. HTTP and raw TCP are two suggested candidates
 (HTTP
 allowing to much more easily reach restricted networks).
 
 1) Going by our decoupling requirement, Shouldn't we think about both HTTP
 and Sockets, treating them as modes of transport under a common interface?
 
 My personal preference is sockets, IMHO the speed and simplicity is
 required. HTTP can be used for authentication and non-real time
 interactions. But when sockets isn't an option, HTTP as fallback will have
 to do.
 
 *3) Routing p2p messages/events in a server-aided network*
 One option is to somehow detect server clusters, send data to one of
 them,
 and let the rest of the cluster servers synchronize to it (locally).
 Alternatively, the originator server can naively send stuff to all
 possible
 destination servers, regardless of the cost.
 
 *4) Routing p2p messages/events in a pure P2P system (5 parts)*
 How to manage to route all wave-stuff if we want to completely get rid of
 servers completely, and only use peers.
 The closest way would be to use a DHT, but huge latency is an unsolved
 problem, and makes it impossible to use for real-time waving.
 No other solution has been proposed.
 
 3, 4) Its possible to start with simplest possible configuration...two
 nodes who have access to each other. Over time we will get more insights
 about this. I don't think connectivity can be done without a set of
 trackers for ALL possible cases, especially between two workstation nodes
 or two mobiles. How about letting people run wave tracker services in
 public domain? Something like oauth providers currently. Its up to you if
 you trust the provider and want to whitelist it or register on it.
 Trackers will only be used initially to make a connection, or again when
 its dropped. Most other models will involve a lot of jumping through hoops.
 We can do KISS initially.
 
 
 *5) Implementing undo: invertibility, tombstones, edge cases, TP2*
 No server means no canonical order of commits, which means that undo is
 hard to do correctly.
 (uhm... not sure if that's a good summary, some stuff went over my head
 :-D, please read the log instead)
 
 5) I may be wrong about this, but is it necessary to do UNDO on OT level?
 Can we not let application handle it depending on how data is interpreted?
 I can see how it can be done easily if the application using the OT layer
 is a code editor. On the other hand, is it safe to even do UNDO in OT layer
 when we are not fully sure about data model and domain constraints?
 
 
 *7) Comparison with BitTorrent and P2P-TV technologies*
 Both technologies are much less restricted than wave with regards to
 real-time responsiveness. So none are really a good reference for our
 purposes.
 
 7) Agreed. p2p file sharing is too casual system to pick up from for our
 use case.
 
 
 
 *8) Identifying participants (3 parts)*
 Pure p2p means many peers don't have a n...@centralized-server.com user
 handle, so an alternative has to be used.
 However, it's easy to provide a traditional friendly handle, if the user
 prefers the tradeoff of having to often rely on a permanent server. This
 tradeoff can be mitigated by using a sort of userhandle cache.
 
 8) Please see 3, 4.
 
 
 On Fri, Jun 21, 2013 at 6:45 PM, Michael MacFadden 
 michael.macfad...@gmail.com wrote:
 
 We should create a section for these topics in the wiki in some sort of
 design space.
 
 ~Michael
 
 On Jun 21, 2013, at 6:06 AM, John Blossom jblos...@gmail.com wrote:
 
 Bruno,
 
 Thanks, this is an excellent summary. It helps me to get the gist of
 things
 more clearly.
 
 On the P2P latency, I don't think that it would be unacceptable to draw a
 line and say that P2P provides limited, non-guaranteed realtime OT or
 that
 it's not realtime OT and more of a syncing mode than a conversation mode.
 That would probably be sufficient for what needs to be done, especially
 since in some instances P2P-enabled Wave sessions may be using MESH
 networks for transport - a key factor in how a lot of experimental
 communications services

Re: Joining as a Mentor

[Michael MacFadden]

Sounds great to me.

On 6/21/13 2:09 PM, Pratik Paranjape pratikparanj...@gmail.com wrote:

+1

And I thought you were already a mentor for Wave! I am sure it wasn't only
me.

Welcome.


On Sat, Jun 22, 2013 at 1:45 AM, Joseph Gentle jose...@gmail.com wrote:

 Sounds good to me. [+1]

 Welcome :)

 -Joseph
 On 21 Jun 2013 12:06, Bruno Gonzalez (aka stenyak) sten...@gmail.com
 wrote:

  +1
 
 
  On Fri, Jun 21, 2013 at 8:41 PM, Alain Levesque
  albon...@wavewatchers.orgwrote:
 
   As wavers I say yes also. Don't know if my answer as some value;-)
  
  
   On Fri, Jun 21, 2013 at 1:34 PM, Yuri Z vega...@gmail.com wrote:
  
Sure, that would be great!
Thanks Christian!
   
   
On Fri, Jun 21, 2013 at 7:19 PM, Christian Grobmeier 
   grobme...@gmail.com
wrote:
   
 Hello Wave'rs,

 as you might know, I am Apache Member and involved in various
 projects. I also have mentored a bunch of podlings, like for
 example
 OpenOffice, OGNL and Onami. Currently I am helping the Ripple
  podling.
 You also have already seen in this list.

 Currently there is Upayavira who does a great job with
mentoring.
  With
 the new activity in this podling I would like to help him,
because
 he
 is the only active mentor currently.

 Now I would like to ask the project if they would like to see me
 stepping up as a mentor.

 Basically I would do the things I currently do, but would also
be
  able
 to sign the reports. If there are no objections, I will notify
the
 IPMC and update the mentors list for Wave.

 Cheers,
 Christian

 --
 http://www.grobmeier.de
 https://www.timeandbill.de

   
  
  
  
   --
   Alain Levesque Wavewatchers
   Wavyemailbeta:*
   *
   *Web Page http://albonobo.com/
   *
  
 
 
 
  --
  Saludos,
   Bruno González
 
  ___
  Jabber: stenyak AT gmail.com
  http://www.stenyak.com
 

Demo Server

[Michael MacFadden]

All,

As soon as we have a release, I am going to put the stable release on two
servers.  One will be my personal server. Another one will be a server
hosted by my company.  I think we we have a couple environments up and
running it will help.

Also, I may be able to set up some sandboxes where we can actually deploy
some of our experiments when we start looking at P2P / Server / Hybrid OT.

~Michael

Re: Demo Server

[Michael MacFadden]

Yes the point would be to get federation up and running.  An providing a
place where we can deploy our new OT containers that will need to
communicate in a distributed way.

On 6/21/13 3:35 PM, Bruno Gonzalez (aka stenyak) sten...@gmail.com
wrote:

That sounds good.

Would it be interesting to apply for a VM at apache for that? I was
thinking on doing so if/when the email bot is finished... (so that both
email and wave discussions of the Apache Wave group can happen under the
umbrella of Apache)

Also, are you planning on enabling federation in some of those servers?


Either way, thanks for the efforts.


On Sat, Jun 22, 2013 at 12:20 AM, Michael MacFadden 
michael.macfad...@gmail.com wrote:

 All,

 As soon as we have a release, I am going to put the stable release on
two
 servers.  One will be my personal server. Another one will be a server
 hosted by my company.  I think we we have a couple environments up and
 running it will help.

 Also, I may be able to set up some sandboxes where we can actually
deploy
 some of our experiments when we start looking at P2P / Server / Hybrid
OT.

 ~Michael





-- 
Saludos,
 Bruno González

___
Jabber: stenyak AT gmail.com
http://www.stenyak.com

Re: Issue with Eclipse project

[Michael MacFadden]

So that's two reasons to push the switch to maven in before the release.
Do we want to do that?  It will solve the Jars issue to.

~Michael

On 6/21/13 4:12 PM, Upayavira u...@odoko.co.uk wrote:

Switching to Maven would give us mvn eclipse:eclipse which would
generate these files for us. We could do the same with Ant, but that
would no doubt take some work.

Upayavira


On Thu, Jun 20, 2013, at 09:52 AM, Yuri Z wrote:
 They are committed to SVN
 
 
 On Thu, Jun 20, 2013 at 11:36 AM, Upayavira u...@odoko.co.uk wrote:
 
  Are te Eclipse classpath and project files committed into SVN, or are
  they generated by ant?
 
  I'd expect there to be an 'ant eclipse' target that generates them,
  hence no license headers.
 
  Upayavira
 
  On Wed, Jun 19, 2013, at 08:57 PM, Ali Lown wrote:
   I suspect that license comment is the problem.
   (I don't use eclipse so simply checked that it looked valid after
   mass-addittion of the licenses).
  
   Commit the fix. (Though this may indicate an upstream bug if eclipse
   can't
   handle comments).
  
   Ali
   On 19 Jun 2013 20:52, Yuri Z vega...@gmail.com wrote:
  
I am having problems with opening the Wave in Eclipse - it says
the
.classpath is corrupted. Does anyone else experience this issue as
  well?
I removed the comment with Apache license and it fixed the issue
for
  me, so
should I commit the fix or it's just me?
   
 

Re: A Very Wavey Plan (P2P!)

[Michael MacFadden]

Joseph,

Notes inline below.

~Michael

On 6/19/13 11:22 AM, Joseph Gentle jose...@gmail.com wrote:

I've given half a dozen talks about ShareJS over the last 3 years, and
almost every time I give a talk, someone asks me whether you can use
ShareJS in a peer-to-peer way instead of just through a single server.

You say it works like subversion. Can it work like Git?
Can you have a document shared between multiple servers?

Sigh no. ShareJS  Wave's algorithms were invented in 1995. Back then,
it was news when someone put up a new website.

What about Wave Federation? Appropriately, it works like IRC, but
using XML. Its complicated, its vulnerable to netsplits and its buggy.
I guess its like IRC except it doesn't actually work.

So lets fix that! Lets modernize wave and make it federate properly.
On the way we have a great opportunity to make it simpler and cleaner.

Agree 100%



To start, I want to build a generic P2P OT container. This is a simple
wrapper that contains a set of OT documents and defines a network
protocol for keeping them in sync. The container needs to be able to
talk to another instance of itself running somewhere else and
syncronize documents between the two instances.

Thats all I want this container to do - it should be as lightweight as
possible, so we can port it to lots of different languages and
environments. I want that code running in websites, in giant server
farms, in vim, and everywhere in between. It won't have any database
code, network code, users or a user interface (though it'll need APIs
to support all of that stuff). At its core it just does OT + protocol
work to syncronize documents.

I strongly suggest we separate the OT Algorithms, the application level
protocol, and the network transport layer.


What are the documents? Well, like ShareJS, I'd like to support
multiple different kinds of data. We'll need to be able to support
wave's conversation model, but I'd also like to support arbitrary
JSON. Doing OT over arbitrary JSON structures would allow other
applications to be built on top of wave, using wave as a data platform
(Glorious messaging bus in the sky). It'd also be super useful for
gadgets and user data.

There's three models I can imagine for what wavelets could look like:

Option 1: All documents in the container have a unique name and a
type. This is how ShareJS works. We could have a JSON type and a
wavelet type. This is simple, but not particularly extensible (it
makes it hard to embed JSON inside a conversation, and vice versa).

Option 2: At the root of every document is a JSON object. Leaves in
the JSON structure can be subdocuments, which could be rich text for
blips, or any other type we think of down the road.

Option 3: We make another layer, which can contain a set of documents.
So, a wavelet could contain a JSON document describing the
conversation structure, some rich text documents for blips and another
JSON document containing gadget data or something. Access control
rules are at the container level. This is (sort of) how wavelets work
today.

If I had to choose, I would choose option #2.  However, I think there are
some design choices that we need to make before we answer this question
categorically.  I thought I would put that in a separate email since it
would be buried here.


The OT itself I imagine building along the lines of Torben Weis's P2P
OT theory that he made in Lightwave:
https://code.google.com/p/lightwave/ . Briefly, every operation gets a
hash (like git). We add tombstones to wave's OT type and remove
invertability, so the transform function supports TP2. We also add a
prune function (inverse transform) which allows the history list to be
reordered (so you don't have to transform out on every site). The hard
part is figuring out which operations to sync, and which operations
need to be reordered. I'd like to go over the details with Michael
MacFadden and anyone else who's interested - there may well be a
better system that we should use instead. If there is, I'd like to
know about it now.

I think this is another interesting area.  One thing to consider is that I
am not sure if the linear model that wave used is even the right option.
If we start manipulating things like JSON Objects, Java Object, XML, or
nested documents, a hierarchical path mechanism may be best.  My other
instinct here is, we should make sure that we base the OT on something
that has been proven to be correct.  There has been some work to evaluate
OT systems and prove that they are correct and solve the proper OT Puzzles
and support the required properties.

Two other things that we need to consider.  Beyond TP1 and TP2, there are
also IP1, IP2, and IP3 that you need to think about if you are going to
support group undo, which in my opinion wave needs to support.  If you
can't undo things in collaboration, then you have problems.

Basically, I am not confident that we know that wave's OT or what is in
lightwave is really what we want.  I am not saying

Re: A Very Wavey Plan (P2P!)

[Michael MacFadden]

Upayavira,


We will put a wiki page together.  We will also have the discussion here.
That said, I would like to select at least three people who sign up to
shepherd the discussion.  Everyone is welcome and the committee members
won't have any specific authority.  I am just looking for people to form a
working group and commit to making sure we can define and meet some
objectives.

~Michael

On 6/19/13 6:25 PM, Upayavira u...@odoko.co.uk wrote:

I'd encourage you to fire up a wiki page and start the discussion here.
I suspect due to te nature of the topic, participants will quickly be
self selecting. 

Upayavira

On Wed, Jun 19, 2013, at 10:11 PM, Joseph Gentle wrote:
 On Wed, Jun 19, 2013 at 1:26 PM, Michael MacFadden
 michael.macfad...@gmail.com wrote:
 To start, I want to build a generic P2P OT container. This is a simple
 wrapper that contains a set of OT documents and defines a network
 protocol for keeping them in sync. The container needs to be able to
 talk to another instance of itself running somewhere else and
 syncronize documents between the two instances.
 
 Thats all I want this container to do - it should be as lightweight as
 possible, so we can port it to lots of different languages and
 environments. I want that code running in websites, in giant server
 farms, in vim, and everywhere in between. It won't have any database
 code, network code, users or a user interface (though it'll need APIs
 to support all of that stuff). At its core it just does OT + protocol
 work to syncronize documents.
 
  I strongly suggest we separate the OT Algorithms, the application
level
  protocol, and the network transport layer.
 
 The network transport layer should definitely be separated out. I'd
 also like to separate out the OT functions themselves (a la
 share/ottypes).
 
 I'm imagining coupling the concurrency control system and the
 application level protocol. This coupling might not be needed - I
 don't know enough yet to be able to tell. I think we should focus on
 figuring out what OT system(s) to use first.
 
 The OT itself I imagine building along the lines of Torben Weis's P2P
 OT theory that he made in Lightwave:
 https://code.google.com/p/lightwave/ . Briefly, every operation gets a
 hash (like git). We add tombstones to wave's OT type and remove
 invertability, so the transform function supports TP2. We also add a
 prune function (inverse transform) which allows the history list to be
 reordered (so you don't have to transform out on every site). The hard
 part is figuring out which operations to sync, and which operations
 need to be reordered. I'd like to go over the details with Michael
 MacFadden and anyone else who's interested - there may well be a
 better system that we should use instead. If there is, I'd like to
 know about it now.
 
  I think this is another interesting area.  One thing to consider is
that I
  am not sure if the linear model that wave used is even the right
option.
  If we start manipulating things like JSON Objects, Java Object, XML,
or
  nested documents, a hierarchical path mechanism may be best.
 
 Yes. For ShareJS's JSON OT type, operations are defined by a path (a
 list) and an operation at that path. I'm not convinced by this design
 anymore - we should definitely discuss it.
 
  My other
  instinct here is, we should make sure that we base the OT on something
  that has been proven to be correct.  There has been some work to
evaluate
  OT systems and prove that they are correct and solve the proper OT
Puzzles
  and support the required properties.
 
  Two other things that we need to consider.  Beyond TP1 and TP2, there
are
  also IP1, IP2, and IP3 that you need to think about if you are going
to
  support group undo, which in my opinion wave needs to support.  If you
  can't undo things in collaboration, then you have problems.
 
 Using tombstones, I don't know how you can implement IP3. I've a mind
 to abandon formal invertibility, and simply rely on undo stacks for
 user level actions. But if we can find an architecture which meets our
 needs and can support invertibility, then that would be even better.
 
  Basically, I am not confident that we know that wave's OT or what is
in
  lightwave is really what we want.  I am not saying that they are not,
I am
  just saying that I don't think we really have stated what we NEED
from the
  OT and then proved that a particular approach salsifies those needs.
  Simply having a demo of something that works in a toy environment is
  likely to have holes that we don't see until much, much later in the
  development cycle.
 
  My recommendation here would be for us to form a small committee to
do a
  literature review on the topic and to foster some technical
discussion.
  The result should be something in the wiki that lays out a plan that
the
  community can comment on.
 
 I completely agree. I don't know enough about what our other choices
 are. You're much better read than I am and you're better connected

Re: Project leads, earning merit, Commit-then-review

[Michael MacFadden]

I somewhat agree with Yuri on this.  I think for the experiments section
we should not require code reviews.  I think the code reviews have been
very helpful for people to collaborate and learn the existing codebase and
has kept it from introducing a lot of instabilities.  I would note that
almost no real code commits have been clean right from the get go.
During the code reviews we have found a lot of things that needed to be
changed.

Pre-reviews force the committer to get the attention of other committers.
If you try to do it after the fact, there is less incentive.

~Michael

On 6/19/13 9:58 PM, Yuri Z vega...@gmail.com wrote:

Hi Upayavira
While reviews are not strictly required by Apache, each community has it's
own culture. The decision to pre review or post review is a trade off.
With
pros and cons on each side.
In my opinion we should to continue to pre review each commit for the
following reasons:

   - Each developer has it's own style, which not necessarily complies
with
   the style of Wave code. IMHO it is very important to keep the style
uniform
   over the whole code base and  the standards should be equally high. It
is
   easy to let the code quality slip down, but very hard to bring it back.
   - Wave code is sometimes complex with many layers of abstractions,
which
   means that's it is easy to break something but hard to fix.
   - Absence of code reviews can hinder adoption of Wave by
   big/governmental organizations that want each line of code to be
reviewed
   by community to reduce the risks of malicious code planted into the
code
   base.
   - Code reviews force open and constructive discussions, which allows to
   to keep the community consensus over the ways the product develops.



On Thu, Jun 20, 2013 at 4:02 AM, Upayavira u...@odoko.co.uk wrote:



 On Wed, Jun 19, 2013, at 03:00 PM, Christian Grobmeier wrote:
  Hi all,
 
  from time to time I see in several projects the term lead developer
  coming up. Sometimes incubating projects are confused also when to
  grant committership.
 
  On the lead developer: the ASF is a do-cracy, as we sometimes say.
  The guy who does things is actually leading it. We do not have a
  hierarchy, like a senior programmer who tells juniors what to do. The
  whole project is leading the project. There are no real managers or
  something like that. The term lead does let non-leads wait before
  they are taking action. But in fact, everybody reading this list is
  invited to take initiative and do things. Even non-committers can
  lead something.
 
  When a non-committer has show commitment to a project, he gets
  invited. Projects have different bars for inviting people. Personally
  I always prefer to set a pretty low bar for earning committership.
  Becoming a PMC member is a different thing. The bar should be higher.
  For example, I think about a candidate if he is around for lets say 3
  months and contributes. Contributions can be answering user questions,
  writing docs, cleaning up Jira, writing code and so on. Translators,
  Community people, they all can become committer.
  After three months it is clear if the person wants to stay around or
not.
 
  The PMC should then open a [DISCUSS] thread on private and speaking
  about the candidate. He should fit to the team. Toxic people can be
  dangerous.
 
  You are project are free to choose when it is time to invite a person.
 
  In the current situation as Incubator podling I would even have a
  lesser bar. In the situation of Wave - complex technology driven by
  less people with less time - the bar should be very low. But this is
  just my opinion. If you agree, work through the mailinglists and
  nominate people.
 
  In general, it needs to be easy to contribute to Wave right now.
  Complex review processes might stop people. I cite Upayavira in the
  hope this thread is more visible:
 
  = review then commit =
  Mature communities usually follow this, when there's substantial risk
in
  making chances. Wave is way to young for this, IMO.
 
  = commit then review =
  This is what I'm used to. Make a commit, and have other developers
watch
  the commit list. They can object on the dev list if they see something
  they don't like, but the basic assumption is that, if you have commit
  rights, we trust you.
 
  I am also a fan of ctr. I agree that Wave is ways to young for rtc.
  Instead, code base must move on as quickly as possible.
 
  Please see this e-mail as suggestion, and not binding.
 
  I want to make sure:
 
  - non-committers know they are invited to perform actions
  - committers know its ok to early invite new people to the project
  (don't be shy)
  - there is the option to commit-then-review - no need for a review
  board in early stages, if you ask me

 No need for reviewboard because that's what the commit mails are for. If
 you are a committer, make sure you are receiving them and do review
 them.

 Upayavira

Re: Wave and OpenOffice

[Michael MacFadden]

All,

What we would need to do to support integration with Open Office, or any
other app, is abstract our OT Core Engine in two ways.  First it would
need to become a stand alone service that other apps could hook in to.
Second we would need to change the operations to be more generic than the
current set that are tied to the wave conversation model. The current OT
model is not flexible enough to become a core OT framework for other apps
to use.

One of the things that always struck me in Wave was that the conversation
model used OT but that the gadget API did not.  This is in part because
gadgets had their own data model which had nothing to do with
conversations (lines, annotations, etc) which were not supported well by
Wave's OT.

The google real time API is a step in that direction, but there are a
couple problems with it.  1) It is a javascript API rather than a service.
2) You are forced to use it's data types rather than your own, and 3) your
data must be stored on Drive.

I have seen two proprietary OT engines that seem to work well acting as a
service and one open source one.  If we are to grow, I think this is the
direction the OT code needs to go in.

I think Joseph and I (so far as I can tell) are probably the two most
interested people in doing this.

I think we need to develop mini communities within wave.  Those that are
focused on the OT / CC Stack, those that are focused on clients, those
that are interested in federation, etc.  If we can pair up some folks that
are interested in each of these areas (and others), I think we can make
some progress.

~Michael

On 6/15/13 8:25 PM, Yuri Z vega...@gmail.com wrote:

Just a note - the rendering to static HTML is experimental and wasn't
actually submitted to official Apache Wave repo since there was no
agreement on the way on how this should implemented right without breaking
static bindings when compiling from GWT to Javascript.


On Sat, Jun 15, 2013 at 10:05 PM, Zachary ³Gamer_Z.² Yaro
zmy...@gmail.comwrote:

 @Fleeky, Yuri actually added some
 code
 
https://github.com/vega113/WaveInCloud/tree/master/src/org/waveprotocol/b
ox/server/rpc/render
 to
 WIAB for static HTML rendering, so that could be a solution to your
 publishing problems.  In addition, Google Wave, Rizzoma, and (I* *think)
 WIAB (with Yuri's code) support exporting to HTML or PDF.  Is that what
you
 were asking for?

 @John, I definitely like the idea of being able to log into a wave
server
 from OpenOffice and edit waves through it, but I think we need a
 standardized wave client-server protocol first.


 ‹Zachary ³Gamer_Z.² Yaro


 On 15 June 2013 12:34, Fleeky Flanco fle...@gmail.com wrote:

  john, i was infact using wave as a google docs replacement for a
while it
  worked pretty good the only problem i had with it was that i couldnt
  'publish' static updates to a front facing page to share with people
who
  didnt feel like registering on my wave server.
 
  an openoffice for wave would be extremely usefull, and could have an
  extremely large impact imo. wave is also already very very close to
 having
  this funcitonality. etherpad lite sortof already does this, but i kept
  going back to wave because it was actually more responsive,
featurefull,
  and actually crashed less.
 
 
 
 
  On Sat, Jun 15, 2013 at 9:29 AM, John Blossom jblos...@gmail.com
 wrote:
 
   I had the down-the-road thought just now that I wanted to put into
   circulation before I forgot about it.
  
   One of the challenges that we will face in developing open source
Wave
 is
   that Google and others - but mostly Google - are out there using
   operational transform technologies also. So far the Google Drive
 Realtime
   API hasn't had much impact, but it's being demoed successfully in
 Drive
   apps like Docs and Presentations.
  
   The advantages of an open source Wave implementation are, of course,
 that
   people can own their own data and identity management without
having to
   rely on a specific vendor's infrastructure. But the flip side of
that
 is
   that you have to look carefully at infrastructure that integrates OT
 and
   understand what you have to do similarly to showcase your
technologies.
  
   That brings me to OpenOffice. At some point it will be beneficial to
   consider how the Wave API can enable apps in the OpenOffice suite to
 take
   advantage of OT technologies in Wave and its other various
features. In
   fact, it's not unthinkable that an OpenOffice for Wave variant might
 not
  be
   feasible at some point, maintaining a familiar office automation
 paradigm
   as a user interface for those who relate to that sort of tool but
 having
   the power of Wave to drive collaborative document editing, comments,
   embedded apps and so on, with Wave data structures underneath the OO
   interface.
  
   Just idle thoughts for now, but if we make good progress over the
next
   several months, it's a sub-project that may help to attract more
  developers
   to Wave technologies.
  

Re: [VOTE RESULT] (was: [VOTE] Release Wave 0.4 based on RC3)

[Michael MacFadden]

I know I asked this before, but when we are ready, just let me know I
would be happy to post the artifact somewhere typical and update the web
site.

I'll also submit some news items to various web sites.

~Michael

On 6/16/13 8:22 AM, Christian Grobmeier grobme...@gmail.com wrote:

Hi Ali,

its ok if you just pass on the link to the vote result. No need to
search for the individual results, its really too much work. though I
appreciate your precision, if you like it like that it's OK. It just
want to save some time :-)

I believe ML update all couple of hours, but I seriously don't know.

Cheers
Christian

On Sat, Jun 15, 2013 at 9:43 PM, Ali Lown a...@apache.org wrote:
 Updated (again) results for RC3:
 
https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201306.mbox/
%3CCABRGrVd6n5_LLWUUfaEkY4kzLDUmd-txyadkMqWKmTfbWTGkSA%40mail.gmail.com%3
E

 +1: 8
 Christian Grobmeier (IPMC)
 
https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201306.mbox/
%3CCAPFNckhyJGt3ttmLQ6g0WfxPJYbjHzQqbg%3Dx3exDA34G6oY8wg%40mail.gmail.com
%3E

 Michael MacFadden (Committer)
 
https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201306.mbox/
%3C595415A4-647A-40F0-A28C-0547B75D%40gmail.com%3E

 Vicente J. Ruiz Jurado (Committer)
 
https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201306.mbox/
%3C51BC3554.1090006%40ourproject.org%3E

 Ali Lown (Committer - Implicit as release manager)

 Angus Turner
 Joseph Gentle
 Pratik Paranjape
 Dave Ball

 +0: 2
 Upayavira (IPMC - [...] Therefore I am voting +0 to say I am
 supportive of the effort that has been done here, believe the right
 things to have been done, but would rather defer to a more
 knowledgable Incubator PMC member when it comes to a formal vote.)
 
https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201306.mbox/
%3C1370764102.20453.140661241682749.624F6C99%40webmail.messagingengine.co
m%3E

 Lennard de Rijk (Committer - I support the effort, I have however not
 fully reviewed this version so I can't state whether I'm completely
 sure it is ready.)
 
https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201306.mbox/
%3CCAK-JFo1bez4O5bkWxQTkAqidO2RxOrJxsp%3DQOywuwVRsVjMOFA%40mail.gmail.com
%3E

 -0: 0

 -1: 0

 Anybody else?

 Ali

 PS. I now have to wait for another few hours, for the web mailing list
 archives to update, so I can get the perma-link for this message so I
 can post it on the incubator list. (How often do they update? It only
 seems to be a few times a day at most)



-- 
http://www.grobmeier.de
https://www.timeandbill.de

Re: Wave and OpenOffice

[Michael MacFadden]

I took a look at walk around when it was first announced.  Admittedly, I
would need to go back and take a look at it again.  I do remember it being
more decoupled than was was in WiaB.  I don't remember if it was (in my
opinion) sufficiently abstract.  I seem to remember there were still
things like Blip Operations and Wavelet Operations, which seemed to be
specific to wave.  As I said, it has been quite a while since I looked at
walk around (over a year), so I would need to go back and look.

On 6/16/13 10:25 AM, Dave w...@glark.co.uk wrote:

On 16/06/13 09:29, Michael MacFadden wrote:
 All,

 What we would need to do to support integration with Open Office, or any
 other app, is abstract our OT Core Engine in two ways.  First it would
 need to become a stand alone service that other apps could hook in to.
 Second we would need to change the operations to be more generic than
the
 current set that are tied to the wave conversation model. The current OT
 model is not flexible enough to become a core OT framework for other
apps
 to use.

Michael,

Have you had a chance to look at the SLOB layer in google walkaround [1]?

quote
Much of the walkaround code is not specific to Wave, but factored out as
a separate, more general collaboration layer that manages shared live
objects. These objects can be modified by multiple clients at the same
time, with changes made by any client immediately broadcast to all
others. The Wave application is built on top of this, but the live
collaboration layer is flexible enough to support other applications.
/quote

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 that the
conversation
 model used OT but that the gadget API did not.  This is in part because
 gadgets had their own data model which had nothing to do with
 conversations (lines, annotations, etc) which were not supported well by
 Wave's OT.

 The google real time API is a step in that direction, but there are a
 couple problems with it.  1) It is a javascript API rather than a
service.
 2) You are forced to use it's data types rather than your own, and 3)
your
 data must be stored on Drive.

 I have seen two proprietary OT engines that seem to work well acting as
a
 service and one open source one.  If we are to grow, I think this is the
 direction the OT code needs to go in.

 I think Joseph and I (so far as I can tell) are probably the two most
 interested people in doing this.

 I think we need to develop mini communities within wave.  Those that are
 focused on the OT / CC Stack, those that are focused on clients, those
 that are interested in federation, etc.  If we can pair up some folks
that
 are interested in each of these areas (and others), I think we can make
 some progress.

 ~Michael

 On 6/15/13 8:25 PM, Yuri Z vega...@gmail.com wrote:

 Just a note - the rendering to static HTML is experimental and wasn't
 actually submitted to official Apache Wave repo since there was no
 agreement on the way on how this should implemented right without
breaking
 static bindings when compiling from GWT to Javascript.


 On Sat, Jun 15, 2013 at 10:05 PM, Zachary ³Gamer_Z.² Yaro
 zmy...@gmail.comwrote:

 @Fleeky, Yuri actually added some
 code

 
https://github.com/vega113/WaveInCloud/tree/master/src/org/waveprotocol
/b
 ox/server/rpc/render
 to
 WIAB for static HTML rendering, so that could be a solution to your
 publishing problems.  In addition, Google Wave, Rizzoma, and (I*
*think)
 WIAB (with Yuri's code) support exporting to HTML or PDF.  Is that
what
 you
 were asking for?

 @John, I definitely like the idea of being able to log into a wave
 server
 from OpenOffice and edit waves through it, but I think we need a
 standardized wave client-server protocol first.


 ‹Zachary ³Gamer_Z.² Yaro


 On 15 June 2013 12:34, Fleeky Flanco fle...@gmail.com wrote:

 john, i was infact using wave as a google docs replacement for a
 while it
 worked pretty good the only problem i had with it was that i couldnt
 'publish' static updates to a front facing page to share with people
 who
 didnt feel like registering on my wave server.

 an openoffice for wave would be extremely usefull, and could have an
 extremely large impact imo. wave is also already very very close to
 having
 this funcitonality. etherpad lite sortof already does this, but i
kept
 going back to wave because it was actually more responsive,
 featurefull,
 and actually crashed less.




 On Sat, Jun 15, 2013 at 9:29 AM, John Blossom jblos...@gmail.com
 wrote:
 I had the down-the-road thought just now that I wanted to put into
 circulation before I forgot about it.

 One of the challenges that we will face in developing open source
 Wave
 is
 that Google and others - but mostly Google - are out there using
 operational transform technologies also. So far the Google Drive
 Realtime
 API hasn't had much impact, but it's being demoed

Re: OpenOffice and Wave

[Michael MacFadden]

Rob,

I would be interested in continuing this conversation. I have been working with 
the top minds in OT for the past few years. I am excited to hear the OO is 
interested in an OT supported mechanism. How far along are you in the process?

~Michael

On Jun 16, 2013, at 11:00 AM, Rob Weir robw...@apache.org wrote:

 I'm not subscribed to this list, but Christian Grobmeier pointed me to
 John's post about how OT and Wave could be relevant to OpenOffice.
 
 I wanted to mention that the idea is being discussed, but at the
 standards level.  The default document format for OpenOffice is Open
 Document Format (ODF), which is standardized at OASIS and ISO.  (I
 chair the committee at OASIS).  We're currently working on ODF 1.3 and
 as part of that we're adding a new change tracking mechanism based on
 OT.  This is the traditional asynchronous change tracking that office
 suites have had for years, but modeled on OT terms.
 
 And, although not specified at this point, we're also aware that OT
 enables more interesting modes of collaboration, including
 synchronous/real-time, co-editing, etc.  That's the main reason the OT
 approach is attractive, is that we can have a single model that will
 work for change tracking as well as co-editing.
 
 Once we get the standard side of this elaborated in more details, then
 the next step will be to get it implemented in Apache OpenOffice as
 well as the Apache ODF Toolit (incubating).  But the pace of
 standardization is slow, and I wouldn't expect this before 2014.
 
 Regards,
 
 -Rob

Re: OpenOffice and Wave

[Michael MacFadden]

After hooking up with Google for wave. I have been the lead architect for an OT 
framework much like the real time drive API being built at my company. I am 
encouraging my developers to reengage the apache community so we can actively 
contribute back. We have also done a in depth literature review regarding OT 
and have worked with many other teams adding OT to several projects. 

I personally will be chairing the 14th International Workshop on Collaborative 
Editing Systems (IWCES) at the ACM Computer Supported Collaborative Work (CSCW) 
conference next February. This workshop is one of the primary places where 
leading OT researchers, industry, and open source projects come to exchange 
ideas.

I think this would be a very good community for you to get involved with if you 
are looking at OT. There are a lot of lessons learned, especially on using OT 
for rich document editing (word, PowerPoint, Vim, etc. ). 

I am sure there are more than enough extremely smart folks on the Open Office 
team, but perhaps I/we could help out if you are not to far along. 

Regards,

~Michael

On Jun 16, 2013, at 6:50 PM, Rob Weir robw...@apache.org wrote:

 Adding Svante Schubert to the thread, from the ODF Toolkit project.
 He also chairs the subcommittee at OASIS that has been looking at OT
 for change tracking in ODF.
 
 
 On Sun, Jun 16, 2013 at 6:15 PM, Michael MacFadden
 michael.macfad...@gmail.com wrote:
 
 
 On 6/16/13 2:51 PM, Michael MacFadden michael.macfad...@gmail.com
 wrote:
 
 Rob,
 
 I would be interested in continuing this conversation. I have been
 working with the top minds in OT for the past few years. I am excited to
 hear the OO is interested in an OT supported mechanism. How far along are
 you in the process?
 
 It is very early and mainly happening in the standards committee at
 OASIS.  The ultimate aim is to have something that could work across
 applications, not just between two OpenOffice instances.  So this
 requires a sensitivity to the document model abstraction, to work at
 the ODF level, not just with an application's internal view of a
 document.
 
 OpenOffice committers are involved in the standardization side of
 this, as well as LibreOffice and Calligra and Gnumeric, as well as
 Microsoft.
 
 Initially it is about defining the document model, in a way that makes
 sense to the user.  Since tracked changes are visible to the user, to
 approve or reject, we need it at a granularity that makes sense to
 them.  Then based on those primitives, and the associated actions, we
 can develop an XML-based notation for expressing the state
 transformations.  That gets us to the static/stored form of
 traditional change tracking.
 
 Not in plan officially is the next step, which would be the protocols
 for exchanging such information in real-time.  But it is a possibility
 (even a likelihood) that is informing our design decisions.  We're
 mindful that the real-time collaborative editing is the logical next
 step and we're trying to lay the right foundations for that at the
 format level.
 
 One sub-goal, for enabling the real-time side of this, would be to
 standardize the protocols at some level, so clients from different
 vendors could do this kind of collaboration in a heterogeneous kind of
 way.  Is there anything in Wave that would be a good basis for a
 standard?
 
 Of course a perfectly valid approach would be to prototype first and
 then standardize.
 
 Regards,
 
 -Rob
 
 
 
 ~Michael
 
 On Jun 16, 2013, at 11:00 AM, Rob Weir robw...@apache.org wrote:
 
 I'm not subscribed to this list, but Christian Grobmeier pointed me to
 John's post about how OT and Wave could be relevant to OpenOffice.
 
 I wanted to mention that the idea is being discussed, but at the
 standards level.  The default document format for OpenOffice is Open
 Document Format (ODF), which is standardized at OASIS and ISO.  (I
 chair the committee at OASIS).  We're currently working on ODF 1.3 and
 as part of that we're adding a new change tracking mechanism based on
 OT.  This is the traditional asynchronous change tracking that office
 suites have had for years, but modeled on OT terms.
 
 And, although not specified at this point, we're also aware that OT
 enables more interesting modes of collaboration, including
 synchronous/real-time, co-editing, etc.  That's the main reason the OT
 approach is attractive, is that we can have a single model that will
 work for change tracking as well as co-editing.
 
 Once we get the standard side of this elaborated in more details, then
 the next step will be to get it implemented in Apache OpenOffice as
 well as the Apache ODF Toolit (incubating).  But the pace of
 standardization is slow, and I wouldn't expect this before 2014.
 
 Regards,
 
 -Rob
 
 
 
 --
 Opinions expressed in this communication reflect the author's
 individual personal view, not necessarily that of an amorphous
 collective.  The above statements do not reflect an official position
 of any organization

Re: OpenOffice and Wave

[Michael MacFadden]

A google hang out amongst wave developers is a great idea. However this is not 
a substitute for presenting and discussing the future of OT with the active 
research community.

~Michael

On Jun 16, 2013, at 5:32 PM, John Blossom jblos...@gmail.com wrote:

 Joseph, my thought is that we can have a Google+ Hangout and invite
 everyone in the Wave community and beyond interested in OT and related
 issues. Doesn't have to be perfect, we just need to get the
 dialogue.rolling, it seems. We can always have more. Say Weds or Thursday
 around 1700 UT+1?  Pick a number. John
 
 All the best,
 
 John Blossom
 
 email: jblos...@gmail.com
 phone: 203.293.8511
 google+: https://google.com/+JohnBlossom
 
 
 On Sun, Jun 16, 2013 at 8:15 PM, Joseph Gentle jose...@gmail.com wrote:
 
 Sounds interesting. Where is this going to be held? It might be
 interesting for a few people on this list, too.
 
 -J
 
 On Sun, Jun 16, 2013 at 4:08 PM, Michael MacFadden
 michael.macfad...@gmail.com wrote:
 After hooking up with Google for wave. I have been the lead architect
 for an OT framework much like the real time drive API being built at my
 company. I am encouraging my developers to reengage the apache community so
 we can actively contribute back. We have also done a in depth literature
 review regarding OT and have worked with many other teams adding OT to
 several projects.
 
 I personally will be chairing the 14th International Workshop on
 Collaborative Editing Systems (IWCES) at the ACM Computer Supported
 Collaborative Work (CSCW) conference next February. This workshop is one of
 the primary places where leading OT researchers, industry, and open source
 projects come to exchange ideas.
 
 I think this would be a very good community for you to get involved with
 if you are looking at OT. There are a lot of lessons learned, especially on
 using OT for rich document editing (word, PowerPoint, Vim, etc. ).
 
 I am sure there are more than enough extremely smart folks on the Open
 Office team, but perhaps I/we could help out if you are not to far along.
 
 Regards,
 
 ~Michael
 
 On Jun 16, 2013, at 6:50 PM, Rob Weir robw...@apache.org wrote:
 
 Adding Svante Schubert to the thread, from the ODF Toolkit project.
 He also chairs the subcommittee at OASIS that has been looking at OT
 for change tracking in ODF.
 
 
 On Sun, Jun 16, 2013 at 6:15 PM, Michael MacFadden
 michael.macfad...@gmail.com wrote:
 
 
 On 6/16/13 2:51 PM, Michael MacFadden michael.macfad...@gmail.com
 wrote:
 
 Rob,
 
 I would be interested in continuing this conversation. I have been
 working with the top minds in OT for the past few years. I am excited
 to
 hear the OO is interested in an OT supported mechanism. How far along
 are
 you in the process?
 
 It is very early and mainly happening in the standards committee at
 OASIS.  The ultimate aim is to have something that could work across
 applications, not just between two OpenOffice instances.  So this
 requires a sensitivity to the document model abstraction, to work at
 the ODF level, not just with an application's internal view of a
 document.
 
 OpenOffice committers are involved in the standardization side of
 this, as well as LibreOffice and Calligra and Gnumeric, as well as
 Microsoft.
 
 Initially it is about defining the document model, in a way that makes
 sense to the user.  Since tracked changes are visible to the user, to
 approve or reject, we need it at a granularity that makes sense to
 them.  Then based on those primitives, and the associated actions, we
 can develop an XML-based notation for expressing the state
 transformations.  That gets us to the static/stored form of
 traditional change tracking.
 
 Not in plan officially is the next step, which would be the protocols
 for exchanging such information in real-time.  But it is a possibility
 (even a likelihood) that is informing our design decisions.  We're
 mindful that the real-time collaborative editing is the logical next
 step and we're trying to lay the right foundations for that at the
 format level.
 
 One sub-goal, for enabling the real-time side of this, would be to
 standardize the protocols at some level, so clients from different
 vendors could do this kind of collaboration in a heterogeneous kind of
 way.  Is there anything in Wave that would be a good basis for a
 standard?
 
 Of course a perfectly valid approach would be to prototype first and
 then standardize.
 
 Regards,
 
 -Rob
 
 
 
 ~Michael
 
 On Jun 16, 2013, at 11:00 AM, Rob Weir robw...@apache.org wrote:
 
 I'm not subscribed to this list, but Christian Grobmeier pointed me
 to
 John's post about how OT and Wave could be relevant to OpenOffice.
 
 I wanted to mention that the idea is being discussed, but at the
 standards level.  The default document format for OpenOffice is Open
 Document Format (ODF), which is standardized at OASIS and ISO.  (I
 chair the committee at OASIS).  We're currently working on ODF 1.3
 and
 as part of that we're adding a new

Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]

[Michael MacFadden]

Joseph,

I disagree.  The annotations themselves are just another data structure.
You add them, remove them and modify them like anything else.  You can
manage annotations as another structure within the blip model.  There is
no reason why you can interface them though a JSON Style operations
structure.

~Michael

On 6/13/13 12:11 AM, Joseph Gentle jose...@gmail.com wrote:

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
michael.macfad...@gmail.com wrote:
 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
 modify the conversation model

 Potentially.


 On 6/12/13 10:55 PM, Joseph Gentle jose...@gmail.com 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 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 storing application data. It'd be nice to have
some sort of hybrid for wavelets where we can put multiple different
kinds of data inside a wavelet. One option is to use a JSON OT type as
the root of all wavelets and support subdocuments at arbitrary paths
(so the object could be:
{projectName:ruby on rails, files:[{name:'foo/bar.rb', ...}],
documentation:{_type:richtext, _data:Rich text data}}

Or wavelets could simply each have a type (defaulting to the current
wavey XML type).

-J


On Wed, Jun 12, 2013 at 2:41 PM, Michael MacFadden
michael.macfad...@gmail.com wrote:
 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, you have to go back and mess with your transformation
 functions.  Not good.  Or you have to try to bend new data models in
to
 the existing one, also not good.

 Best practice is to create a generic OT model and operate on that.
There
 is debate as to what the model should be, but most agree on the
concept.

 For example in wave they tried to create a map like collection that OT
 could operate on. Essentially though that had to implement the map as
if
 its underlying model was a bunch of XMLish type tags.  This we very
 convoluted.

 ~Michael

 On 6/12/13 10:26 PM, Joseph Gentle jose...@gmail.com wrote:

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, Jun 12, 2013 at 1:56 PM, Bruno Gonzalez (aka stenyak)
sten...@gmail.com wrote:
 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 unfortunate consequence, you can then only
OT-operate
on
 plain text. Otherwise you could get conflict-free xml text that
looks
 likethis, and that of course isn't legal xml.
 But we still want rich text in Google Wave, therefore all the
formatting
 stuff is stored some place else, specifically in the blip
annotations.
The
 modifications to annotations are (sometimes) simply derived from the
 transformations that the plain text suffers after merges?

 I suppose there could be other OT algorithms that don't use a
character
 primitive, but rather an xml tag primitive, a json item, a
pixel,
or
 anything else, right?

 (sorry for only contributing with questions... :-)


 On Wed, Jun 12, 2013 at 10:27 PM, Joseph Gentle jose...@gmail.com
wrote:

 On Wed, Jun 12, 2013 at 12:13 PM, Bruno Gonzalez (aka stenyak)
 sten...@gmail.com 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
  conflicts eliminated by choosing an arbitrary merging strategy
when
  conflicts *do* happen (e.g. choose the last timestamped patch
and
lose
  information on the way, we don't care), or can they be prevented
from
 ever
  happening in the first place?

 They're inevitable in patch based systems because patches usually
have
 a line level granularity. OT usually uses

Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]

[Michael MacFadden]

No that is not it at all.  You misunderstand my comments.  I am not
actually suggesting you store ANYTHING in a JSON string.  The point is
that the wave model store as Objects. There is an actual object some where
in memory that defines the text, lines, annotations etc.

When you do operations in ShareJS, are you really thinking about JSON
Objects a strings in the JSON format, or are you thinking about
manipulating an object.  I think it is the latter.  Looking at your API,
you have methods at add things to arrays and set properties.  So your
operational language is aligned to manipulating object models.

As such you could manipulate any arbitrary object structure, a JSON
object, a wave document model, etc.

~Michael

On 6/13/13 7:54 PM, Joseph Gentle jose...@gmail.com wrote:

So you're imagining storing rich text like this?

{doc: 'hi there!', annotations: [{from:0, to:2, bold:true}]} or something?

Every change to the document is going to need to manually update every
single annotation which has start / end points after the edit. But it
wouldn't work - if you insert some text and I edit an annotation later
in the document, my annotation will float forwards / backwards when I
get your op because I don't know how I should change it.

This idea comes up about every 6 months on the sharejs mailing list.
Several solutions have been proposed, but none of them work correctly.
I think we just need a separate set of transform / apply / ...
functions for rich text.

-J


On Thu, Jun 13, 2013 at 1:19 AM, Michael MacFadden
michael.macfad...@gmail.com wrote:
 Joseph,

 I disagree.  The annotations themselves are just another data structure.
 You add them, remove them and modify them like anything else.  You can
 manage annotations as another structure within the blip model.  There is
 no reason why you can interface them though a JSON Style operations
 structure.

 ~Michael

 On 6/13/13 12:11 AM, Joseph Gentle jose...@gmail.com wrote:

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
michael.macfad...@gmail.com wrote:
 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
 modify the conversation model

 Potentially.


 On 6/12/13 10:55 PM, Joseph Gentle jose...@gmail.com 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 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 storing application data. It'd be nice to have
some sort of hybrid for wavelets where we can put multiple different
kinds of data inside a wavelet. One option is to use a JSON OT type as
the root of all wavelets and support subdocuments at arbitrary paths
(so the object could be:
{projectName:ruby on rails, files:[{name:'foo/bar.rb', ...}],
documentation:{_type:richtext, _data:Rich text data}}

Or wavelets could simply each have a type (defaulting to the current
wavey XML type).

-J


On Wed, Jun 12, 2013 at 2:41 PM, Michael MacFadden
michael.macfad...@gmail.com wrote:
 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, you have to go back and mess with your transformation
 functions.  Not good.  Or you have to try to bend new data models in
to
 the existing one, also not good.

 Best practice is to create a generic OT model and operate on that.
There
 is debate as to what the model should be, but most agree on the
concept.

 For example in wave they tried to create a map like collection that
OT
 could operate on. Essentially though that had to implement the map
as
if
 its underlying model was a bunch of XMLish type tags.  This we very
 convoluted.

 ~Michael

 On 6/12/13 10:26 PM, Joseph Gentle jose...@gmail.com wrote:

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, Jun 12, 2013 at 1:56 PM, Bruno Gonzalez (aka stenyak)
sten...@gmail.com wrote:
 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

Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]

[Michael MacFadden]

As a follow up.  The reason you are struggling with the concept is that
you have tied the operation language directly to a specific data model, in
much the way wave did.  They created a conversation model and a specific
set of operations that act on that model.  When you do that your
operations a making assumptions on how the object model works.  This
coupling is not a good idea.  Much of the OT community strongly recommends
avoiding this.

Rather great a generic set of operations that manipulate things in an
abstract way, and then let the application sort out what to do with the
operations when it receives it.  The OT stack only needs to understand how
the parameters of the operations interact; such as positional arguments
for insert and delete style operations.  The OT Stack doesn't need to know
that the thing you are inserting is a character, a contact card, a
database record, or an object in a list.  It doesn't care.  It just knows
that if one insert happens before another it has to increment the index of
the second operation.

If things are decoupled in this way, the whole OT stack becomes much more
flexible.  As one of the founders of OT says almost every time I see him,
Let OT focus on what it is good at, and let it ignore everything else.

~Michael

On 6/13/13 7:54 PM, Joseph Gentle jose...@gmail.com wrote:

So you're imagining storing rich text like this?

{doc: 'hi there!', annotations: [{from:0, to:2, bold:true}]} or something?

Every change to the document is going to need to manually update every
single annotation which has start / end points after the edit. But it
wouldn't work - if you insert some text and I edit an annotation later
in the document, my annotation will float forwards / backwards when I
get your op because I don't know how I should change it.

This idea comes up about every 6 months on the sharejs mailing list.
Several solutions have been proposed, but none of them work correctly.
I think we just need a separate set of transform / apply / ...
functions for rich text.

-J


On Thu, Jun 13, 2013 at 1:19 AM, Michael MacFadden
michael.macfad...@gmail.com wrote:
 Joseph,

 I disagree.  The annotations themselves are just another data structure.
 You add them, remove them and modify them like anything else.  You can
 manage annotations as another structure within the blip model.  There is
 no reason why you can interface them though a JSON Style operations
 structure.

 ~Michael

 On 6/13/13 12:11 AM, Joseph Gentle jose...@gmail.com wrote:

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
michael.macfad...@gmail.com wrote:
 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
 modify the conversation model

 Potentially.


 On 6/12/13 10:55 PM, Joseph Gentle jose...@gmail.com 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 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 storing application data. It'd be nice to have
some sort of hybrid for wavelets where we can put multiple different
kinds of data inside a wavelet. One option is to use a JSON OT type as
the root of all wavelets and support subdocuments at arbitrary paths
(so the object could be:
{projectName:ruby on rails, files:[{name:'foo/bar.rb', ...}],
documentation:{_type:richtext, _data:Rich text data}}

Or wavelets could simply each have a type (defaulting to the current
wavey XML type).

-J


On Wed, Jun 12, 2013 at 2:41 PM, Michael MacFadden
michael.macfad...@gmail.com wrote:
 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, you have to go back and mess with your transformation
 functions.  Not good.  Or you have to try to bend new data models in
to
 the existing one, also not good.

 Best practice is to create a generic OT model and operate on that.
There
 is debate as to what the model should be, but most agree on the
concept.

 For example in wave they tried to create a map like collection that
OT
 could operate on. Essentially though that had to implement the map
as
if
 its underlying model was a bunch of XMLish type tags.  This we very
 convoluted.

 ~Michael

 On 6/12/13 10:26 PM, Joseph Gentle jose

Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]

[Michael MacFadden]

Joseph,

We are almost in sync now.  Lets go one step further.  Let's so you were
designing an application to be a rich text editor.  Forget OT, you just
making an editor.  I assume your editor has to have some sort of model
right?  Let's temporarily forget the persistence format.  You may save the
rich text to xml, or rtf, or whatever, but I am not worried about that.  I
am saying what is the in memory model that your editor uses to interact
with the document?  Build that.  Build it any way you like.

Ok so now you have a rich text object model.  Your editor is going to
interact with that though some sort of object model API.  When the user
selects some text and presses the bold button, the editor makes some API
call to the model and says, make this part bold.  For the sake of
conversation, I don't care how that internally happens in the object data
model.

OK.  So now if we have a sufficiently powerful OT operation set can
describe manipulating objects, we can manipulate the object model with OT.
 Really what OT services are, are robust message busses that describe how
one user is changing the objects to another user, and accounting for
context transformations along the way.  So if you can build an abstract OT
operation set that lets you mess with objects and objects structures, then
you have a shot at then adapting that operation set to a whole slew of
applications.

This is actually an ongoing area of research, that I presented a paper on
to the collaborative editing workshop at the ACM CSCW conference last year.

~Michael

On 6/13/13 8:34 PM, Joseph Gentle jose...@gmail.com wrote:

Interesting...

The abstraction I use is to have a bunch of data types. Each data type
defines what documents look like, what operations look like and they
define a set of OT functions (transform, compose, apply, etc). Eg,
Text documents are strings and their operations are lists of {skip:5},
{insert:'hi'}, {delete:10}, etc. JSON documents are JSON and their
operations are lists of path+what to do there. Eg, [{path: ['hi'],
delete list element 5}, ...]

It sounds like you're saying we should abstract over the ideas of
ot-for-lists, ot-for-sets and so on. Is that right?

... But rich text isn't quite a list or a set. You can make annotation
markers or something, but then they take up space. Maybe its possible
to ignore the final document space that an annotation takes up for the
purpose of transformation?

Another architecture I've thought about using is making all documents
use the JSON OT code. Specialized type like rich text can exist as
leaves in the JSON structure - and let you embed a rich text operation
inside a JSON operation.

-J


On Thu, Jun 13, 2013 at 12:05 PM, Michael MacFadden
michael.macfad...@gmail.com wrote:
 As a follow up.  The reason you are struggling with the concept is that
 you have tied the operation language directly to a specific data model,
in
 much the way wave did.  They created a conversation model and a specific
 set of operations that act on that model.  When you do that your
 operations a making assumptions on how the object model works.  This
 coupling is not a good idea.  Much of the OT community strongly
recommends
 avoiding this.

 Rather great a generic set of operations that manipulate things in an
 abstract way, and then let the application sort out what to do with the
 operations when it receives it.  The OT stack only needs to understand
how
 the parameters of the operations interact; such as positional arguments
 for insert and delete style operations.  The OT Stack doesn't need to
know
 that the thing you are inserting is a character, a contact card, a
 database record, or an object in a list.  It doesn't care.  It just
knows
 that if one insert happens before another it has to increment the index
of
 the second operation.

 If things are decoupled in this way, the whole OT stack becomes much
more
 flexible.  As one of the founders of OT says almost every time I see
him,
 Let OT focus on what it is good at, and let it ignore everything else.

 ~Michael

 On 6/13/13 7:54 PM, Joseph Gentle jose...@gmail.com wrote:

So you're imagining storing rich text like this?

{doc: 'hi there!', annotations: [{from:0, to:2, bold:true}]} or
something?

Every change to the document is going to need to manually update every
single annotation which has start / end points after the edit. But it
wouldn't work - if you insert some text and I edit an annotation later
in the document, my annotation will float forwards / backwards when I
get your op because I don't know how I should change it.

This idea comes up about every 6 months on the sharejs mailing list.
Several solutions have been proposed, but none of them work correctly.
I think we just need a separate set of transform / apply / ...
functions for rich text.

-J


On Thu, Jun 13, 2013 at 1:19 AM, Michael MacFadden
michael.macfad...@gmail.com wrote:
 Joseph,

 I disagree.  The annotations themselves are just another data
structure.
 You add

Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]

[Michael MacFadden]

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 proven to be non-feasible
due to the overhead of the protocol and it's expectation for long lived
TCP connections.

During the wave summit, there was an overwhelming desire to remove XMPP in
favor of something more lightweight.  Not much came of that.

~Michael

On 6/12/13 11:09 AM, Yuri Z vega...@gmail.com wrote:

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.


On Wed, Jun 12, 2013 at 10:13 AM, Bruno Gonzalez (aka stenyak) 
sten...@gmail.com wrote:

 On Tue, Jun 11, 2013 at 11:38 PM, Joseph Gentle jose...@gmail.com
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 work with codebases which were millions
  of lines long. How do we manage big projects? How well does eclipse
  scale? How do we refactor codebases that size?
 
  This is crazy. The right question isn't How do we scale our tools,
  its How do I write less java?.
 
 
 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 = settingsManager.get(key);

 But after 20 minutes traversing the code, writing each variable many
times
 in different files, with different syntaxes (camel case, underscore
 separators, all-caps, and whatnot) throughout several code layers, I
still
 hadn't managed to reach the point of code where I actually wanted my
bot to
 use the damned settings. I'm all for future-proofing the design, but I
 think that's a bit ridiculous. I don't want to imagine the fun in
debugging
 federation and ot algorithms when they fail, if it's all written like
this.

 Ali and I half-joked about going on a killing spree to halve the amount
of
 code. I'm sure no practical functionality would be lost... :-)

 --
 Saludos,
  Bruno González

 ___
 Jabber: stenyak AT gmail.com
 http://www.stenyak.com

Re: Wave Future Options

[Michael MacFadden]

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 take MUCH longer to modularize the code than it would to start over.

On the other hand, I am not sure that starting over is feasible either.  I
really don't know.

~Michael

On 6/12/13 11:26 AM, Paulo Pires pjpi...@ubiwhere.com wrote:

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 OT.

Also, moving things from a strong-typed language and powerful framework
like Java to Python or Ruby or Node.js or whatever you believe is the new
kid on the block, seems a little nonsense to me. People just don't
understand Wave internals and won't be able to implement it whatever
technologies you choose.
Also, writing things from scratch seem a little far fetched, as I doubt
anyone will be able to take on that task for the medium/long term.

Please don't take me wrong here, but I've seen plenty discussion like
this in other big projects and the result was ultimately the same, too
much talk, no code. I wouldn't like this to happen to Wave.

PP

On Jun 12, 2013, at 10:28 AM, Michael MacFadden
michael.macfad...@gmail.com wrote:

 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
 somewhat functional and is what the community is using to drive towards
a
 release.  However, the current community has little expedience with the
code
 base.  We didn't designed it and in many cases we don't understand it.
 
 As many have pointed out the code base is 1) Not easy to develop, 2)
Hard to
 learn, 3) and not modularized between the client and server.  These
issues
 are hampering WiaB's adoption.
 
 Several people have suggested rewriting the codebase to separate the
server
 and client and to greatly simplify the architecture.
 
 
 
 I think as a community we need to decide what we want to do.  I have put
 forth three options which I would like the community to comment on.
 
 
 1) Keep the current code base and just push ahead.
 
 Pros:
 - 
 - We have a functional codebase that we evolve over time.
 - Potentially graduate sooner.
 
 Cons:
 -
 - Hard to get new developers excited about working with the code base.
 - Poetnetially slows the evolution of a scalable architecture that
delivers
 what the community is asking for.
 
 
 2) Ditch the current code base and start new.
 
 Pros:
 -
 - We can design something that meets the community needs.
 - We can simply the design from the beginning.
 
 Cons:
 -
 - We are very close to a release, this approach would set back future
 releases.
 
 
 3) Keep the current code base AND start a new one.
 
 Pros:
 -
 - Can keep driving through the apache process.
 - We still have a working product.
 - We can start the redesign now.
 
 Cons:
 -
 - We barely have enough developers to maintain the current codebase.
 - If interest in the new codebase takes off, existing codebase would
 atrophy.
 
 
 Comments please.  Thanks.
 
 ~Michael