You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wave-dev@incubator.apache.org by Price Clark <gp...@gmail.com> on 2016/10/01 16:40:05 UTC
Re: SwellRT tech overview
Pablo, thanks for the presentation.
While my qualifications to answer this are 0 getting to listen to
Upayavira talk this week (the last Apache mentor if I'm not mistaken) make
me feel the answers to 1 and 2 are easy to answer.
1.) Upayavira communicated very fervently that there just isn't enough
oomph in wave's development. Every year around the time that the retirement
conversation is brought up, activity similar to this starts brewing and
then it all dies down in a few months. From this perspective "Does SwellRT
tackle current Wave problems?" The answer is unequivocally yes, SwellRT is
a more actively maintained fork of Wave and given the slowing/slowed pace
of Wave *a merge with SwellRT is likely the only way to save this project*.
2.) I would also like to bring up another point Upayavira made,
"Communities are built around good ideas and bad code." Running with that I
thing that good ideas attract tinkerers and 'people with ideas' that could
eventually become 'contributors with ideas'. In some senses SwellRT
splinters Apache Wave in a way that developers on this mailing list have
been alluding to for a while. The client side code is not well understood
and is definitely in the way of the server. SwellRT has a more general goal
of supplying a server that is capable of powering a front-end like the
original vision of google wave. This means that merging with SwellRT would
force a separation of the client and server and allow for people with
interests in either a front or back end to work in tandem. This seems like
an ingenious way to attract more people; anyone with an interest in the
backend technology OR a way to use said technology in an application could
be a potential contributor. Unless I'm mistaken it seems like SwellRT
offers a set of features that could be classified as a superset of Wave's
features. So, it seems like most or all of SwellRT would be at home in
Wave. Pablo also reasonably stated that he'd prefer to work in one project.
As for me, as soon as a direction is clear I would love to talk to
someone actively maintaining/writing code so I can help them contribute to
whichever code survives in whatever way possible.
Re: Invite to the github project for Wave...
Posted by Adam John <aj...@sterlingsolved.com>.
Had to rename the project due to naming rights.
The preferred one to join might be:
https://github.com/P2Pvalue/swellrt
Adam John
(914) 623-8433
On Oct 15, 2016 2:52 PM, "Bradley D. Thornton" <Br...@northtech.us> wrote:
> Hello,
>
> I received an invite to ApacheWave at github but upon trying to accept the
> invite it appears to be a broken link that results in a 404 error.
>
> Does anyone have the correct URL or could someone send me another invite?
>
> Thanks!
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
Invite to the github project for Wave...
Posted by "Bradley D. Thornton" <Br...@NorthTech.US>.
Hello,
I received an invite to ApacheWave at github but upon trying to accept
the invite it appears to be a broken link that results in a 404 error.
Does anyone have the correct URL or could someone send me another invite?
Thanks!
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: SwellRT tech overview
Posted by Pablo Ojanguren <pa...@gmail.com>.
Following up Upayavira, I will be very glad to help anyone wanting to
start with SwellRT's source code. In this regard I suggest...
a) invite you all to *join our Gitter chat *(
https://gitter.im/P2Pvalue/swellrt) to reach me out and other SwellRT
contributors, and ask directly doubts, just chat about what can be done, or
just know us better. Please consider timezone, we are based on Spain
(GMT+2) ;)
b) encourage you to *share here your desires* about what would you like to
do in order to discover shared interests (for example, lately I am thinking
about to reimplement Wave server using Akka framework (http://akka.io/),
to complete the Android client and to manage wave's snapshots instead of
deltas when waves are loaded)
Also someone would prefer to code UI, in that case checkout the
SwellRT-based text editor built with Angular2:
https://github.com/P2Pvalue/swellrt-pad / http://jetpad-int.devialab.rocks/
c) to schedule *video calls to explain tech details* about SwellRT and also
I will be happy to explain any original Wave's code part I know.
Thomas:
I think the simplest idea is SwellRT become main branch and to add recent
Wave's work if it is necessary.
Of course, any documentation and resources would be given to Wave too.
2016-10-12 15:08 GMT+02:00 Thomas Wrobel <da...@gmail.com>:
> If we are doing things for SwellRTs benefit, it seems like it should
> all be upto Pablo to me.
> As the main developer of SwellRT he has the most to risk, and any
> requirements or prerequisites he feels necessary to mitage that risk
> he should specify and we should accommodate.
> I certainly don't want any harm to come to the work that has been done
> on SwellRT.
>
> I just feel adding a prerequisite at apaches end of "we need more
> people active at SwellRT" is a bit weird after being given such a
> generous offer.
>
> ---
>
> * Adam - Indeed the link seems to be for proposal for things entering
> incubation. I think aspects of the voting section still make sense
> though. Certainly both a summery and details of the proposal is
> needed.
>
> Last I heard the plan was simply to let SwellRT become the main
> branch. So no code merging as such, just a replacement with this fork
> (with the acknowledgement of some recent work might be lost at Apaches
> side).
>
> SwellRT has good documentation of its API etc, so presumably this also
> would also be brought in somehow?
>
Re: SwellRT tech overview
Posted by Thomas Wrobel <da...@gmail.com>.
If we are doing things for SwellRTs benefit, it seems like it should
all be upto Pablo to me.
As the main developer of SwellRT he has the most to risk, and any
requirements or prerequisites he feels necessary to mitage that risk
he should specify and we should accommodate.
I certainly don't want any harm to come to the work that has been done
on SwellRT.
I just feel adding a prerequisite at apaches end of "we need more
people active at SwellRT" is a bit weird after being given such a
generous offer.
---
* Adam - Indeed the link seems to be for proposal for things entering
incubation. I think aspects of the voting section still make sense
though. Certainly both a summery and details of the proposal is
needed.
Last I heard the plan was simply to let SwellRT become the main
branch. So no code merging as such, just a replacement with this fork
(with the acknowledgement of some recent work might be lost at Apaches
side).
SwellRT has good documentation of its API etc, so presumably this also
would also be brought in somehow?
Re: SwellRT tech overview
Posted by Michael MacFadden <mi...@gmail.com>.
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" <uv...@odoko.co.uk> 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
> <https://docs.google.com/document/d/1jhPRR9juJAhBBZ9qjYI5KxlaHSz-IJJdPQ6_3puwWBQ/edit?usp=sharing>
> 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+ <http://google.com/+AdamJohn1> | LinkedIn
> <http://mradamjohn.com/>
>
> On Mon, Oct 10, 2016 at 5:00 PM, Thomas Wrobel <da...@gmail.com>
> 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 <pa...@gmail.com> 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 there is still a part of the world
> > > happy to see a Java friendly framework, despite it works for Web (but
> > > hopefully for android/iOS).
> > >
> > > - Simpler API: with sugar syntax, for example, in SwellRT we are working
> > in
> > > a JS syntax just based in mutable objects. Also with API concepts easy to
> > > understand: objects and participants.
> > >
> > > - Full-featured collaborative writing: Wave was designed for text
> > editing,
> > > whereas these new frameworks are focused in JSON. For example,
> > annotations
> > > is a cool feature not easy to provide I guess. Also the Wave's text
> > editor
> > > is very good yet.
> > >
> > > - Federation: it is the hardest selling point for developers in general
> > > because it doesn't provide benefits in the short term. However, it is the
> > > entrance to innovative things like cross-app interoperability, organic
> > > scalability...
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2016-10-05 23:47 GMT+02:00 Upayavira <uv...@odoko.co.uk>:
> > >
> > >> I want to see a proposal regarding importing SwellRT that gives me
> > >> confidence that bringing SwellRT into Wave will actually lead to an
> > >> active project.
> > >>
> > >> A way this could be achieved *before* bringing SwellRT would be if
> > >> everyone who is interested in contributing headed over to SwellRT, and
> > >> started contributing over there. Then, we'd be bringing both code and
> > >> community into Apache, which would give me far more confidence than just
> > >> importing code but with no confidence that anyone is actually going to
> > >> do anything with it.
> > >>
> > >> Upayavira
> > >>
> > >> On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote:
> > >> > Pablo, a lot of great information in this slide deck. I hope others
> > have
> > >> > a
> > >> > chance to review as well. Outstanding work.
> > >> >
> > >> > Price, very thoughtful responses. I agree with the overall
> > conclusion -
> > >> > SwellRT should be brought into Wave.
> > >> >
> > >> > I like the idea of moving the SwellRT fork in to replace the current
> > >> > branch
> > >> > of Wave development because it moves the project reasonably forward
> > and
> > >> > makes sense overall. It does not seem anything current would be lost
> > in
> > >> > that move. It seems like we have everything to gain. However, there
> > >> > might
> > >> > be work in progress that is affected.
> > >> >
> > >> > It would be great if contributors on the project took a look and
> > shared
> > >> > some thoughts.
> > >> >
> > >> > Q3) For current contributors; are you in favor of bringing the fork
> > home?
> > >> >
> > >> > -
> > >> > Great attendance at our last meeting, and familiar ground was covered.
> > >> > (agenda
> > >> > and notes
> > >> > <https://docs.google.com/document/d/11j_
> > WQGYAtDlN8Wqx8jJglPpw6tJznvMGf
> > >> dLOvQu96i0/edit>)
> > >> > We're largely covering the next steps in recent emails.
> > >> >
> > >> > If the group agrees, that we should bring SwellRT into Apache Wave,
> > then
> > >> > there needs to be a proposal drafted.
> > >> >
> > >> > Q4) Does anyone have interest, experience or desire to help with this
> > >> > task? We do not expect to start until after the next meeting.
> > >> >
> > >> > -
> > >> > Perhaps 2-3 weeks is time enough to consider the questions posed?
> > >> > I'd like to plan our next steps;
> > >> > I suggest *10/26 as the next discussion* - based on consensus in the
> > list
> > >> > of course.
> > >> >
> > >> > The goal of the next meeting will be to provide a chance to address
> > any
> > >> > questions regarding bringing the projects together. Perhaps this
> > could
> > >> > be
> > >> > a technically deeper discussion.
> > >> >
> > >> > Q5) Does anyone have interest in a standing co-work session?
> > Especially
> > >> > important would be current contributors. I think this could be a good
> > >> > way
> > >> > for some on the list that have stalled or reached impasse to begin to
> > >> > make
> > >> > progress in helping out.
> > >> >
> > >> > Thanks, everyone for your work and efforts. I believe that if each
> > of us
> > >> > does just a little bit over the next few weeks we will continue to see
> > >> > the
> > >> > progress we need in this project.
> > >> >
> > >> > Adam John
> > >> > (914) 623-8433
> > >> > Google+ <http://google.com/+AdamJohn1> | LinkedIn
> > >> > <http://mradamjohn.com/>
> > >> >
> > >> > On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pa...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Thanks for your answer Price,
> > >> > >
> > >> > > I guess we should not delay this discussion...
> > >> > >
> > >> > > I'd happy to run another call if you think it can move things
> > forward.
> > >> > >
> > >> > >
> > >> > >
> > >> > > 2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
> > >> > >
> > >> > > > Pablo, thanks for the presentation.
> > >> > > >
> > >> > > > While my qualifications to answer this are 0 getting to listen to
> > >> > > > Upayavira talk this week (the last Apache mentor if I'm not
> > mistaken)
> > >> > > make
> > >> > > > me feel the answers to 1 and 2 are easy to answer.
> > >> > > >
> > >> > > > 1.) Upayavira communicated very fervently that there just isn't
> > >> enough
> > >> > > > oomph in wave's development. Every year around the time that the
> > >> > > retirement
> > >> > > > conversation is brought up, activity similar to this starts
> > brewing
> > >> and
> > >> > > > then it all dies down in a few months. From this perspective "Does
> > >> > > SwellRT
> > >> > > > tackle current Wave problems?" The answer is unequivocally yes,
> > >> SwellRT
> > >> > > is
> > >> > > > a more actively maintained fork of Wave and given the
> > slowing/slowed
> > >> pace
> > >> > > > of Wave *a merge with SwellRT is likely the only way to save this
> > >> > > project*.
> > >> > > >
> > >> > > > 2.) I would also like to bring up another point Upayavira made,
> > >> > > > "Communities are built around good ideas and bad code." Running
> > with
> > >> > > that I
> > >> > > > thing that good ideas attract tinkerers and 'people with ideas'
> > that
> > >> > > could
> > >> > > > eventually become 'contributors with ideas'. In some senses
> > SwellRT
> > >> > > > splinters Apache Wave in a way that developers on this mailing
> > list
> > >> have
> > >> > > > been alluding to for a while. The client side code is not well
> > >> understood
> > >> > > > and is definitely in the way of the server. SwellRT has a more
> > >> general
> > >> > > goal
> > >> > > > of supplying a server that is capable of powering a front-end like
> > >> the
> > >> > > > original vision of google wave. This means that merging with
> > SwellRT
> > >> > > would
> > >> > > > force a separation of the client and server and allow for people
> > with
> > >> > > > interests in either a front or back end to work in tandem. This
> > seems
> > >> > > like
> > >> > > > an ingenious way to attract more people; anyone with an interest
> > in
> > >> the
> > >> > > > backend technology OR a way to use said technology in an
> > application
> > >> > > could
> > >> > > > be a potential contributor. Unless I'm mistaken it seems like
> > SwellRT
> > >> > > > offers a set of features that could be classified as a superset of
> > >> Wave's
> > >> > > > features. So, it seems like most or all of SwellRT would be at
> > home
> > >> in
> > >> > > > Wave. Pablo also reasonably stated that he'd prefer to work in one
> > >> > > project.
> > >> > > >
> > >> > > > As for me, as soon as a direction is clear I would love to talk to
> > >> > > > someone actively maintaining/writing code so I can help them
> > >> contribute
> > >> > > to
> > >> > > > whichever code survives in whatever way possible.
> > >> > > >
> > >> > >
> > >>
> >
Re: SwellRT tech overview
Posted by Upayavira <uv...@odoko.co.uk>.
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
> <https://docs.google.com/document/d/1jhPRR9juJAhBBZ9qjYI5KxlaHSz-IJJdPQ6_3puwWBQ/edit?usp=sharing>
> 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+ <http://google.com/+AdamJohn1> | LinkedIn
> <http://mradamjohn.com/>
>
> On Mon, Oct 10, 2016 at 5:00 PM, Thomas Wrobel <da...@gmail.com>
> 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 <pa...@gmail.com> 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 there is still a part of the world
> > > happy to see a Java friendly framework, despite it works for Web (but
> > > hopefully for android/iOS).
> > >
> > > - Simpler API: with sugar syntax, for example, in SwellRT we are working
> > in
> > > a JS syntax just based in mutable objects. Also with API concepts easy to
> > > understand: objects and participants.
> > >
> > > - Full-featured collaborative writing: Wave was designed for text
> > editing,
> > > whereas these new frameworks are focused in JSON. For example,
> > annotations
> > > is a cool feature not easy to provide I guess. Also the Wave's text
> > editor
> > > is very good yet.
> > >
> > > - Federation: it is the hardest selling point for developers in general
> > > because it doesn't provide benefits in the short term. However, it is the
> > > entrance to innovative things like cross-app interoperability, organic
> > > scalability...
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2016-10-05 23:47 GMT+02:00 Upayavira <uv...@odoko.co.uk>:
> > >
> > >> I want to see a proposal regarding importing SwellRT that gives me
> > >> confidence that bringing SwellRT into Wave will actually lead to an
> > >> active project.
> > >>
> > >> A way this could be achieved *before* bringing SwellRT would be if
> > >> everyone who is interested in contributing headed over to SwellRT, and
> > >> started contributing over there. Then, we'd be bringing both code and
> > >> community into Apache, which would give me far more confidence than just
> > >> importing code but with no confidence that anyone is actually going to
> > >> do anything with it.
> > >>
> > >> Upayavira
> > >>
> > >> On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote:
> > >> > Pablo, a lot of great information in this slide deck. I hope others
> > have
> > >> > a
> > >> > chance to review as well. Outstanding work.
> > >> >
> > >> > Price, very thoughtful responses. I agree with the overall
> > conclusion -
> > >> > SwellRT should be brought into Wave.
> > >> >
> > >> > I like the idea of moving the SwellRT fork in to replace the current
> > >> > branch
> > >> > of Wave development because it moves the project reasonably forward
> > and
> > >> > makes sense overall. It does not seem anything current would be lost
> > in
> > >> > that move. It seems like we have everything to gain. However, there
> > >> > might
> > >> > be work in progress that is affected.
> > >> >
> > >> > It would be great if contributors on the project took a look and
> > shared
> > >> > some thoughts.
> > >> >
> > >> > Q3) For current contributors; are you in favor of bringing the fork
> > home?
> > >> >
> > >> > -
> > >> > Great attendance at our last meeting, and familiar ground was covered.
> > >> > (agenda
> > >> > and notes
> > >> > <https://docs.google.com/document/d/11j_
> > WQGYAtDlN8Wqx8jJglPpw6tJznvMGf
> > >> dLOvQu96i0/edit>)
> > >> > We're largely covering the next steps in recent emails.
> > >> >
> > >> > If the group agrees, that we should bring SwellRT into Apache Wave,
> > then
> > >> > there needs to be a proposal drafted.
> > >> >
> > >> > Q4) Does anyone have interest, experience or desire to help with this
> > >> > task? We do not expect to start until after the next meeting.
> > >> >
> > >> > -
> > >> > Perhaps 2-3 weeks is time enough to consider the questions posed?
> > >> > I'd like to plan our next steps;
> > >> > I suggest *10/26 as the next discussion* - based on consensus in the
> > list
> > >> > of course.
> > >> >
> > >> > The goal of the next meeting will be to provide a chance to address
> > any
> > >> > questions regarding bringing the projects together. Perhaps this
> > could
> > >> > be
> > >> > a technically deeper discussion.
> > >> >
> > >> > Q5) Does anyone have interest in a standing co-work session?
> > Especially
> > >> > important would be current contributors. I think this could be a good
> > >> > way
> > >> > for some on the list that have stalled or reached impasse to begin to
> > >> > make
> > >> > progress in helping out.
> > >> >
> > >> > Thanks, everyone for your work and efforts. I believe that if each
> > of us
> > >> > does just a little bit over the next few weeks we will continue to see
> > >> > the
> > >> > progress we need in this project.
> > >> >
> > >> > Adam John
> > >> > (914) 623-8433
> > >> > Google+ <http://google.com/+AdamJohn1> | LinkedIn
> > >> > <http://mradamjohn.com/>
> > >> >
> > >> > On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pa...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Thanks for your answer Price,
> > >> > >
> > >> > > I guess we should not delay this discussion...
> > >> > >
> > >> > > I'd happy to run another call if you think it can move things
> > forward.
> > >> > >
> > >> > >
> > >> > >
> > >> > > 2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
> > >> > >
> > >> > > > Pablo, thanks for the presentation.
> > >> > > >
> > >> > > > While my qualifications to answer this are 0 getting to listen to
> > >> > > > Upayavira talk this week (the last Apache mentor if I'm not
> > mistaken)
> > >> > > make
> > >> > > > me feel the answers to 1 and 2 are easy to answer.
> > >> > > >
> > >> > > > 1.) Upayavira communicated very fervently that there just isn't
> > >> enough
> > >> > > > oomph in wave's development. Every year around the time that the
> > >> > > retirement
> > >> > > > conversation is brought up, activity similar to this starts
> > brewing
> > >> and
> > >> > > > then it all dies down in a few months. From this perspective "Does
> > >> > > SwellRT
> > >> > > > tackle current Wave problems?" The answer is unequivocally yes,
> > >> SwellRT
> > >> > > is
> > >> > > > a more actively maintained fork of Wave and given the
> > slowing/slowed
> > >> pace
> > >> > > > of Wave *a merge with SwellRT is likely the only way to save this
> > >> > > project*.
> > >> > > >
> > >> > > > 2.) I would also like to bring up another point Upayavira made,
> > >> > > > "Communities are built around good ideas and bad code." Running
> > with
> > >> > > that I
> > >> > > > thing that good ideas attract tinkerers and 'people with ideas'
> > that
> > >> > > could
> > >> > > > eventually become 'contributors with ideas'. In some senses
> > SwellRT
> > >> > > > splinters Apache Wave in a way that developers on this mailing
> > list
> > >> have
> > >> > > > been alluding to for a while. The client side code is not well
> > >> understood
> > >> > > > and is definitely in the way of the server. SwellRT has a more
> > >> general
> > >> > > goal
> > >> > > > of supplying a server that is capable of powering a front-end like
> > >> the
> > >> > > > original vision of google wave. This means that merging with
> > SwellRT
> > >> > > would
> > >> > > > force a separation of the client and server and allow for people
> > with
> > >> > > > interests in either a front or back end to work in tandem. This
> > seems
> > >> > > like
> > >> > > > an ingenious way to attract more people; anyone with an interest
> > in
> > >> the
> > >> > > > backend technology OR a way to use said technology in an
> > application
> > >> > > could
> > >> > > > be a potential contributor. Unless I'm mistaken it seems like
> > SwellRT
> > >> > > > offers a set of features that could be classified as a superset of
> > >> Wave's
> > >> > > > features. So, it seems like most or all of SwellRT would be at
> > home
> > >> in
> > >> > > > Wave. Pablo also reasonably stated that he'd prefer to work in one
> > >> > > project.
> > >> > > >
> > >> > > > As for me, as soon as a direction is clear I would love to talk to
> > >> > > > someone actively maintaining/writing code so I can help them
> > >> contribute
> > >> > > to
> > >> > > > whichever code survives in whatever way possible.
> > >> > > >
> > >> > >
> > >>
> >
Re: SwellRT tech overview
Posted by Adam John <aj...@sterlingsolved.com>.
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
<https://docs.google.com/document/d/1jhPRR9juJAhBBZ9qjYI5KxlaHSz-IJJdPQ6_3puwWBQ/edit?usp=sharing>
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+ <http://google.com/+AdamJohn1> | LinkedIn <http://mradamjohn.com/>
On Mon, Oct 10, 2016 at 5:00 PM, Thomas Wrobel <da...@gmail.com> 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 <pa...@gmail.com> 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 there is still a part of the world
> > happy to see a Java friendly framework, despite it works for Web (but
> > hopefully for android/iOS).
> >
> > - Simpler API: with sugar syntax, for example, in SwellRT we are working
> in
> > a JS syntax just based in mutable objects. Also with API concepts easy to
> > understand: objects and participants.
> >
> > - Full-featured collaborative writing: Wave was designed for text
> editing,
> > whereas these new frameworks are focused in JSON. For example,
> annotations
> > is a cool feature not easy to provide I guess. Also the Wave's text
> editor
> > is very good yet.
> >
> > - Federation: it is the hardest selling point for developers in general
> > because it doesn't provide benefits in the short term. However, it is the
> > entrance to innovative things like cross-app interoperability, organic
> > scalability...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2016-10-05 23:47 GMT+02:00 Upayavira <uv...@odoko.co.uk>:
> >
> >> I want to see a proposal regarding importing SwellRT that gives me
> >> confidence that bringing SwellRT into Wave will actually lead to an
> >> active project.
> >>
> >> A way this could be achieved *before* bringing SwellRT would be if
> >> everyone who is interested in contributing headed over to SwellRT, and
> >> started contributing over there. Then, we'd be bringing both code and
> >> community into Apache, which would give me far more confidence than just
> >> importing code but with no confidence that anyone is actually going to
> >> do anything with it.
> >>
> >> Upayavira
> >>
> >> On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote:
> >> > Pablo, a lot of great information in this slide deck. I hope others
> have
> >> > a
> >> > chance to review as well. Outstanding work.
> >> >
> >> > Price, very thoughtful responses. I agree with the overall
> conclusion -
> >> > SwellRT should be brought into Wave.
> >> >
> >> > I like the idea of moving the SwellRT fork in to replace the current
> >> > branch
> >> > of Wave development because it moves the project reasonably forward
> and
> >> > makes sense overall. It does not seem anything current would be lost
> in
> >> > that move. It seems like we have everything to gain. However, there
> >> > might
> >> > be work in progress that is affected.
> >> >
> >> > It would be great if contributors on the project took a look and
> shared
> >> > some thoughts.
> >> >
> >> > Q3) For current contributors; are you in favor of bringing the fork
> home?
> >> >
> >> > -
> >> > Great attendance at our last meeting, and familiar ground was covered.
> >> > (agenda
> >> > and notes
> >> > <https://docs.google.com/document/d/11j_
> WQGYAtDlN8Wqx8jJglPpw6tJznvMGf
> >> dLOvQu96i0/edit>)
> >> > We're largely covering the next steps in recent emails.
> >> >
> >> > If the group agrees, that we should bring SwellRT into Apache Wave,
> then
> >> > there needs to be a proposal drafted.
> >> >
> >> > Q4) Does anyone have interest, experience or desire to help with this
> >> > task? We do not expect to start until after the next meeting.
> >> >
> >> > -
> >> > Perhaps 2-3 weeks is time enough to consider the questions posed?
> >> > I'd like to plan our next steps;
> >> > I suggest *10/26 as the next discussion* - based on consensus in the
> list
> >> > of course.
> >> >
> >> > The goal of the next meeting will be to provide a chance to address
> any
> >> > questions regarding bringing the projects together. Perhaps this
> could
> >> > be
> >> > a technically deeper discussion.
> >> >
> >> > Q5) Does anyone have interest in a standing co-work session?
> Especially
> >> > important would be current contributors. I think this could be a good
> >> > way
> >> > for some on the list that have stalled or reached impasse to begin to
> >> > make
> >> > progress in helping out.
> >> >
> >> > Thanks, everyone for your work and efforts. I believe that if each
> of us
> >> > does just a little bit over the next few weeks we will continue to see
> >> > the
> >> > progress we need in this project.
> >> >
> >> > Adam John
> >> > (914) 623-8433
> >> > Google+ <http://google.com/+AdamJohn1> | LinkedIn
> >> > <http://mradamjohn.com/>
> >> >
> >> > On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pa...@gmail.com>
> >> > wrote:
> >> >
> >> > > Thanks for your answer Price,
> >> > >
> >> > > I guess we should not delay this discussion...
> >> > >
> >> > > I'd happy to run another call if you think it can move things
> forward.
> >> > >
> >> > >
> >> > >
> >> > > 2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
> >> > >
> >> > > > Pablo, thanks for the presentation.
> >> > > >
> >> > > > While my qualifications to answer this are 0 getting to listen to
> >> > > > Upayavira talk this week (the last Apache mentor if I'm not
> mistaken)
> >> > > make
> >> > > > me feel the answers to 1 and 2 are easy to answer.
> >> > > >
> >> > > > 1.) Upayavira communicated very fervently that there just isn't
> >> enough
> >> > > > oomph in wave's development. Every year around the time that the
> >> > > retirement
> >> > > > conversation is brought up, activity similar to this starts
> brewing
> >> and
> >> > > > then it all dies down in a few months. From this perspective "Does
> >> > > SwellRT
> >> > > > tackle current Wave problems?" The answer is unequivocally yes,
> >> SwellRT
> >> > > is
> >> > > > a more actively maintained fork of Wave and given the
> slowing/slowed
> >> pace
> >> > > > of Wave *a merge with SwellRT is likely the only way to save this
> >> > > project*.
> >> > > >
> >> > > > 2.) I would also like to bring up another point Upayavira made,
> >> > > > "Communities are built around good ideas and bad code." Running
> with
> >> > > that I
> >> > > > thing that good ideas attract tinkerers and 'people with ideas'
> that
> >> > > could
> >> > > > eventually become 'contributors with ideas'. In some senses
> SwellRT
> >> > > > splinters Apache Wave in a way that developers on this mailing
> list
> >> have
> >> > > > been alluding to for a while. The client side code is not well
> >> understood
> >> > > > and is definitely in the way of the server. SwellRT has a more
> >> general
> >> > > goal
> >> > > > of supplying a server that is capable of powering a front-end like
> >> the
> >> > > > original vision of google wave. This means that merging with
> SwellRT
> >> > > would
> >> > > > force a separation of the client and server and allow for people
> with
> >> > > > interests in either a front or back end to work in tandem. This
> seems
> >> > > like
> >> > > > an ingenious way to attract more people; anyone with an interest
> in
> >> the
> >> > > > backend technology OR a way to use said technology in an
> application
> >> > > could
> >> > > > be a potential contributor. Unless I'm mistaken it seems like
> SwellRT
> >> > > > offers a set of features that could be classified as a superset of
> >> Wave's
> >> > > > features. So, it seems like most or all of SwellRT would be at
> home
> >> in
> >> > > > Wave. Pablo also reasonably stated that he'd prefer to work in one
> >> > > project.
> >> > > >
> >> > > > As for me, as soon as a direction is clear I would love to talk to
> >> > > > someone actively maintaining/writing code so I can help them
> >> contribute
> >> > > to
> >> > > > whichever code survives in whatever way possible.
> >> > > >
> >> > >
> >>
>
Re: SwellRT tech overview
Posted by Upayavira <uv...@odoko.co.uk>.
My concern is not for Wave, it is for SwellRT. The last thing I'd want
is them (I don't know how many of them there are) to move over to
Apache, only to find out that the match with Apache isn't sufficient,
and Wave closes down anyway. I want to be sure we can avoid that
eventuality, and the best way I can see to accomplish that, assuming
Pablo is okay with it, is for anyone interested in SwellRT development
moving to Apache, is to go and join the SwellRT community. Go start
contributing to the code where it is now. Then we can form a realistic
view of what we are going to bring into Apache before we do it.
Upayavira
On Mon, 10 Oct 2016, at 10: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 <pa...@gmail.com> 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 there is still a part of the world
> > happy to see a Java friendly framework, despite it works for Web (but
> > hopefully for android/iOS).
> >
> > - Simpler API: with sugar syntax, for example, in SwellRT we are working in
> > a JS syntax just based in mutable objects. Also with API concepts easy to
> > understand: objects and participants.
> >
> > - Full-featured collaborative writing: Wave was designed for text editing,
> > whereas these new frameworks are focused in JSON. For example, annotations
> > is a cool feature not easy to provide I guess. Also the Wave's text editor
> > is very good yet.
> >
> > - Federation: it is the hardest selling point for developers in general
> > because it doesn't provide benefits in the short term. However, it is the
> > entrance to innovative things like cross-app interoperability, organic
> > scalability...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2016-10-05 23:47 GMT+02:00 Upayavira <uv...@odoko.co.uk>:
> >
> >> I want to see a proposal regarding importing SwellRT that gives me
> >> confidence that bringing SwellRT into Wave will actually lead to an
> >> active project.
> >>
> >> A way this could be achieved *before* bringing SwellRT would be if
> >> everyone who is interested in contributing headed over to SwellRT, and
> >> started contributing over there. Then, we'd be bringing both code and
> >> community into Apache, which would give me far more confidence than just
> >> importing code but with no confidence that anyone is actually going to
> >> do anything with it.
> >>
> >> Upayavira
> >>
> >> On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote:
> >> > Pablo, a lot of great information in this slide deck. I hope others have
> >> > a
> >> > chance to review as well. Outstanding work.
> >> >
> >> > Price, very thoughtful responses. I agree with the overall conclusion -
> >> > SwellRT should be brought into Wave.
> >> >
> >> > I like the idea of moving the SwellRT fork in to replace the current
> >> > branch
> >> > of Wave development because it moves the project reasonably forward and
> >> > makes sense overall. It does not seem anything current would be lost in
> >> > that move. It seems like we have everything to gain. However, there
> >> > might
> >> > be work in progress that is affected.
> >> >
> >> > It would be great if contributors on the project took a look and shared
> >> > some thoughts.
> >> >
> >> > Q3) For current contributors; are you in favor of bringing the fork home?
> >> >
> >> > -
> >> > Great attendance at our last meeting, and familiar ground was covered.
> >> > (agenda
> >> > and notes
> >> > <https://docs.google.com/document/d/11j_WQGYAtDlN8Wqx8jJglPpw6tJznvMGf
> >> dLOvQu96i0/edit>)
> >> > We're largely covering the next steps in recent emails.
> >> >
> >> > If the group agrees, that we should bring SwellRT into Apache Wave, then
> >> > there needs to be a proposal drafted.
> >> >
> >> > Q4) Does anyone have interest, experience or desire to help with this
> >> > task? We do not expect to start until after the next meeting.
> >> >
> >> > -
> >> > Perhaps 2-3 weeks is time enough to consider the questions posed?
> >> > I'd like to plan our next steps;
> >> > I suggest *10/26 as the next discussion* - based on consensus in the list
> >> > of course.
> >> >
> >> > The goal of the next meeting will be to provide a chance to address any
> >> > questions regarding bringing the projects together. Perhaps this could
> >> > be
> >> > a technically deeper discussion.
> >> >
> >> > Q5) Does anyone have interest in a standing co-work session? Especially
> >> > important would be current contributors. I think this could be a good
> >> > way
> >> > for some on the list that have stalled or reached impasse to begin to
> >> > make
> >> > progress in helping out.
> >> >
> >> > Thanks, everyone for your work and efforts. I believe that if each of us
> >> > does just a little bit over the next few weeks we will continue to see
> >> > the
> >> > progress we need in this project.
> >> >
> >> > Adam John
> >> > (914) 623-8433
> >> > Google+ <http://google.com/+AdamJohn1> | LinkedIn
> >> > <http://mradamjohn.com/>
> >> >
> >> > On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pa...@gmail.com>
> >> > wrote:
> >> >
> >> > > Thanks for your answer Price,
> >> > >
> >> > > I guess we should not delay this discussion...
> >> > >
> >> > > I'd happy to run another call if you think it can move things forward.
> >> > >
> >> > >
> >> > >
> >> > > 2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
> >> > >
> >> > > > Pablo, thanks for the presentation.
> >> > > >
> >> > > > While my qualifications to answer this are 0 getting to listen to
> >> > > > Upayavira talk this week (the last Apache mentor if I'm not mistaken)
> >> > > make
> >> > > > me feel the answers to 1 and 2 are easy to answer.
> >> > > >
> >> > > > 1.) Upayavira communicated very fervently that there just isn't
> >> enough
> >> > > > oomph in wave's development. Every year around the time that the
> >> > > retirement
> >> > > > conversation is brought up, activity similar to this starts brewing
> >> and
> >> > > > then it all dies down in a few months. From this perspective "Does
> >> > > SwellRT
> >> > > > tackle current Wave problems?" The answer is unequivocally yes,
> >> SwellRT
> >> > > is
> >> > > > a more actively maintained fork of Wave and given the slowing/slowed
> >> pace
> >> > > > of Wave *a merge with SwellRT is likely the only way to save this
> >> > > project*.
> >> > > >
> >> > > > 2.) I would also like to bring up another point Upayavira made,
> >> > > > "Communities are built around good ideas and bad code." Running with
> >> > > that I
> >> > > > thing that good ideas attract tinkerers and 'people with ideas' that
> >> > > could
> >> > > > eventually become 'contributors with ideas'. In some senses SwellRT
> >> > > > splinters Apache Wave in a way that developers on this mailing list
> >> have
> >> > > > been alluding to for a while. The client side code is not well
> >> understood
> >> > > > and is definitely in the way of the server. SwellRT has a more
> >> general
> >> > > goal
> >> > > > of supplying a server that is capable of powering a front-end like
> >> the
> >> > > > original vision of google wave. This means that merging with SwellRT
> >> > > would
> >> > > > force a separation of the client and server and allow for people with
> >> > > > interests in either a front or back end to work in tandem. This seems
> >> > > like
> >> > > > an ingenious way to attract more people; anyone with an interest in
> >> the
> >> > > > backend technology OR a way to use said technology in an application
> >> > > could
> >> > > > be a potential contributor. Unless I'm mistaken it seems like SwellRT
> >> > > > offers a set of features that could be classified as a superset of
> >> Wave's
> >> > > > features. So, it seems like most or all of SwellRT would be at home
> >> in
> >> > > > Wave. Pablo also reasonably stated that he'd prefer to work in one
> >> > > project.
> >> > > >
> >> > > > As for me, as soon as a direction is clear I would love to talk to
> >> > > > someone actively maintaining/writing code so I can help them
> >> contribute
> >> > > to
> >> > > > whichever code survives in whatever way possible.
> >> > > >
> >> > >
> >>
Re: SwellRT tech overview
Posted by Thomas Wrobel <da...@gmail.com>.
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 <pa...@gmail.com> 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 there is still a part of the world
> happy to see a Java friendly framework, despite it works for Web (but
> hopefully for android/iOS).
>
> - Simpler API: with sugar syntax, for example, in SwellRT we are working in
> a JS syntax just based in mutable objects. Also with API concepts easy to
> understand: objects and participants.
>
> - Full-featured collaborative writing: Wave was designed for text editing,
> whereas these new frameworks are focused in JSON. For example, annotations
> is a cool feature not easy to provide I guess. Also the Wave's text editor
> is very good yet.
>
> - Federation: it is the hardest selling point for developers in general
> because it doesn't provide benefits in the short term. However, it is the
> entrance to innovative things like cross-app interoperability, organic
> scalability...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2016-10-05 23:47 GMT+02:00 Upayavira <uv...@odoko.co.uk>:
>
>> I want to see a proposal regarding importing SwellRT that gives me
>> confidence that bringing SwellRT into Wave will actually lead to an
>> active project.
>>
>> A way this could be achieved *before* bringing SwellRT would be if
>> everyone who is interested in contributing headed over to SwellRT, and
>> started contributing over there. Then, we'd be bringing both code and
>> community into Apache, which would give me far more confidence than just
>> importing code but with no confidence that anyone is actually going to
>> do anything with it.
>>
>> Upayavira
>>
>> On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote:
>> > Pablo, a lot of great information in this slide deck. I hope others have
>> > a
>> > chance to review as well. Outstanding work.
>> >
>> > Price, very thoughtful responses. I agree with the overall conclusion -
>> > SwellRT should be brought into Wave.
>> >
>> > I like the idea of moving the SwellRT fork in to replace the current
>> > branch
>> > of Wave development because it moves the project reasonably forward and
>> > makes sense overall. It does not seem anything current would be lost in
>> > that move. It seems like we have everything to gain. However, there
>> > might
>> > be work in progress that is affected.
>> >
>> > It would be great if contributors on the project took a look and shared
>> > some thoughts.
>> >
>> > Q3) For current contributors; are you in favor of bringing the fork home?
>> >
>> > -
>> > Great attendance at our last meeting, and familiar ground was covered.
>> > (agenda
>> > and notes
>> > <https://docs.google.com/document/d/11j_WQGYAtDlN8Wqx8jJglPpw6tJznvMGf
>> dLOvQu96i0/edit>)
>> > We're largely covering the next steps in recent emails.
>> >
>> > If the group agrees, that we should bring SwellRT into Apache Wave, then
>> > there needs to be a proposal drafted.
>> >
>> > Q4) Does anyone have interest, experience or desire to help with this
>> > task? We do not expect to start until after the next meeting.
>> >
>> > -
>> > Perhaps 2-3 weeks is time enough to consider the questions posed?
>> > I'd like to plan our next steps;
>> > I suggest *10/26 as the next discussion* - based on consensus in the list
>> > of course.
>> >
>> > The goal of the next meeting will be to provide a chance to address any
>> > questions regarding bringing the projects together. Perhaps this could
>> > be
>> > a technically deeper discussion.
>> >
>> > Q5) Does anyone have interest in a standing co-work session? Especially
>> > important would be current contributors. I think this could be a good
>> > way
>> > for some on the list that have stalled or reached impasse to begin to
>> > make
>> > progress in helping out.
>> >
>> > Thanks, everyone for your work and efforts. I believe that if each of us
>> > does just a little bit over the next few weeks we will continue to see
>> > the
>> > progress we need in this project.
>> >
>> > Adam John
>> > (914) 623-8433
>> > Google+ <http://google.com/+AdamJohn1> | LinkedIn
>> > <http://mradamjohn.com/>
>> >
>> > On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pa...@gmail.com>
>> > wrote:
>> >
>> > > Thanks for your answer Price,
>> > >
>> > > I guess we should not delay this discussion...
>> > >
>> > > I'd happy to run another call if you think it can move things forward.
>> > >
>> > >
>> > >
>> > > 2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
>> > >
>> > > > Pablo, thanks for the presentation.
>> > > >
>> > > > While my qualifications to answer this are 0 getting to listen to
>> > > > Upayavira talk this week (the last Apache mentor if I'm not mistaken)
>> > > make
>> > > > me feel the answers to 1 and 2 are easy to answer.
>> > > >
>> > > > 1.) Upayavira communicated very fervently that there just isn't
>> enough
>> > > > oomph in wave's development. Every year around the time that the
>> > > retirement
>> > > > conversation is brought up, activity similar to this starts brewing
>> and
>> > > > then it all dies down in a few months. From this perspective "Does
>> > > SwellRT
>> > > > tackle current Wave problems?" The answer is unequivocally yes,
>> SwellRT
>> > > is
>> > > > a more actively maintained fork of Wave and given the slowing/slowed
>> pace
>> > > > of Wave *a merge with SwellRT is likely the only way to save this
>> > > project*.
>> > > >
>> > > > 2.) I would also like to bring up another point Upayavira made,
>> > > > "Communities are built around good ideas and bad code." Running with
>> > > that I
>> > > > thing that good ideas attract tinkerers and 'people with ideas' that
>> > > could
>> > > > eventually become 'contributors with ideas'. In some senses SwellRT
>> > > > splinters Apache Wave in a way that developers on this mailing list
>> have
>> > > > been alluding to for a while. The client side code is not well
>> understood
>> > > > and is definitely in the way of the server. SwellRT has a more
>> general
>> > > goal
>> > > > of supplying a server that is capable of powering a front-end like
>> the
>> > > > original vision of google wave. This means that merging with SwellRT
>> > > would
>> > > > force a separation of the client and server and allow for people with
>> > > > interests in either a front or back end to work in tandem. This seems
>> > > like
>> > > > an ingenious way to attract more people; anyone with an interest in
>> the
>> > > > backend technology OR a way to use said technology in an application
>> > > could
>> > > > be a potential contributor. Unless I'm mistaken it seems like SwellRT
>> > > > offers a set of features that could be classified as a superset of
>> Wave's
>> > > > features. So, it seems like most or all of SwellRT would be at home
>> in
>> > > > Wave. Pablo also reasonably stated that he'd prefer to work in one
>> > > project.
>> > > >
>> > > > As for me, as soon as a direction is clear I would love to talk to
>> > > > someone actively maintaining/writing code so I can help them
>> contribute
>> > > to
>> > > > whichever code survives in whatever way possible.
>> > > >
>> > >
>>
Re: SwellRT tech overview
Posted by Pablo Ojanguren <pa...@gmail.com>.
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 there is still a part of the world
happy to see a Java friendly framework, despite it works for Web (but
hopefully for android/iOS).
- Simpler API: with sugar syntax, for example, in SwellRT we are working in
a JS syntax just based in mutable objects. Also with API concepts easy to
understand: objects and participants.
- Full-featured collaborative writing: Wave was designed for text editing,
whereas these new frameworks are focused in JSON. For example, annotations
is a cool feature not easy to provide I guess. Also the Wave's text editor
is very good yet.
- Federation: it is the hardest selling point for developers in general
because it doesn't provide benefits in the short term. However, it is the
entrance to innovative things like cross-app interoperability, organic
scalability...
2016-10-05 23:47 GMT+02:00 Upayavira <uv...@odoko.co.uk>:
> I want to see a proposal regarding importing SwellRT that gives me
> confidence that bringing SwellRT into Wave will actually lead to an
> active project.
>
> A way this could be achieved *before* bringing SwellRT would be if
> everyone who is interested in contributing headed over to SwellRT, and
> started contributing over there. Then, we'd be bringing both code and
> community into Apache, which would give me far more confidence than just
> importing code but with no confidence that anyone is actually going to
> do anything with it.
>
> Upayavira
>
> On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote:
> > Pablo, a lot of great information in this slide deck. I hope others have
> > a
> > chance to review as well. Outstanding work.
> >
> > Price, very thoughtful responses. I agree with the overall conclusion -
> > SwellRT should be brought into Wave.
> >
> > I like the idea of moving the SwellRT fork in to replace the current
> > branch
> > of Wave development because it moves the project reasonably forward and
> > makes sense overall. It does not seem anything current would be lost in
> > that move. It seems like we have everything to gain. However, there
> > might
> > be work in progress that is affected.
> >
> > It would be great if contributors on the project took a look and shared
> > some thoughts.
> >
> > Q3) For current contributors; are you in favor of bringing the fork home?
> >
> > -
> > Great attendance at our last meeting, and familiar ground was covered.
> > (agenda
> > and notes
> > <https://docs.google.com/document/d/11j_WQGYAtDlN8Wqx8jJglPpw6tJznvMGf
> dLOvQu96i0/edit>)
> > We're largely covering the next steps in recent emails.
> >
> > If the group agrees, that we should bring SwellRT into Apache Wave, then
> > there needs to be a proposal drafted.
> >
> > Q4) Does anyone have interest, experience or desire to help with this
> > task? We do not expect to start until after the next meeting.
> >
> > -
> > Perhaps 2-3 weeks is time enough to consider the questions posed?
> > I'd like to plan our next steps;
> > I suggest *10/26 as the next discussion* - based on consensus in the list
> > of course.
> >
> > The goal of the next meeting will be to provide a chance to address any
> > questions regarding bringing the projects together. Perhaps this could
> > be
> > a technically deeper discussion.
> >
> > Q5) Does anyone have interest in a standing co-work session? Especially
> > important would be current contributors. I think this could be a good
> > way
> > for some on the list that have stalled or reached impasse to begin to
> > make
> > progress in helping out.
> >
> > Thanks, everyone for your work and efforts. I believe that if each of us
> > does just a little bit over the next few weeks we will continue to see
> > the
> > progress we need in this project.
> >
> > Adam John
> > (914) 623-8433
> > Google+ <http://google.com/+AdamJohn1> | LinkedIn
> > <http://mradamjohn.com/>
> >
> > On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pa...@gmail.com>
> > wrote:
> >
> > > Thanks for your answer Price,
> > >
> > > I guess we should not delay this discussion...
> > >
> > > I'd happy to run another call if you think it can move things forward.
> > >
> > >
> > >
> > > 2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
> > >
> > > > Pablo, thanks for the presentation.
> > > >
> > > > While my qualifications to answer this are 0 getting to listen to
> > > > Upayavira talk this week (the last Apache mentor if I'm not mistaken)
> > > make
> > > > me feel the answers to 1 and 2 are easy to answer.
> > > >
> > > > 1.) Upayavira communicated very fervently that there just isn't
> enough
> > > > oomph in wave's development. Every year around the time that the
> > > retirement
> > > > conversation is brought up, activity similar to this starts brewing
> and
> > > > then it all dies down in a few months. From this perspective "Does
> > > SwellRT
> > > > tackle current Wave problems?" The answer is unequivocally yes,
> SwellRT
> > > is
> > > > a more actively maintained fork of Wave and given the slowing/slowed
> pace
> > > > of Wave *a merge with SwellRT is likely the only way to save this
> > > project*.
> > > >
> > > > 2.) I would also like to bring up another point Upayavira made,
> > > > "Communities are built around good ideas and bad code." Running with
> > > that I
> > > > thing that good ideas attract tinkerers and 'people with ideas' that
> > > could
> > > > eventually become 'contributors with ideas'. In some senses SwellRT
> > > > splinters Apache Wave in a way that developers on this mailing list
> have
> > > > been alluding to for a while. The client side code is not well
> understood
> > > > and is definitely in the way of the server. SwellRT has a more
> general
> > > goal
> > > > of supplying a server that is capable of powering a front-end like
> the
> > > > original vision of google wave. This means that merging with SwellRT
> > > would
> > > > force a separation of the client and server and allow for people with
> > > > interests in either a front or back end to work in tandem. This seems
> > > like
> > > > an ingenious way to attract more people; anyone with an interest in
> the
> > > > backend technology OR a way to use said technology in an application
> > > could
> > > > be a potential contributor. Unless I'm mistaken it seems like SwellRT
> > > > offers a set of features that could be classified as a superset of
> Wave's
> > > > features. So, it seems like most or all of SwellRT would be at home
> in
> > > > Wave. Pablo also reasonably stated that he'd prefer to work in one
> > > project.
> > > >
> > > > As for me, as soon as a direction is clear I would love to talk to
> > > > someone actively maintaining/writing code so I can help them
> contribute
> > > to
> > > > whichever code survives in whatever way possible.
> > > >
> > >
>
Re: SwellRT tech overview
Posted by Upayavira <uv...@odoko.co.uk>.
I want to see a proposal regarding importing SwellRT that gives me
confidence that bringing SwellRT into Wave will actually lead to an
active project.
A way this could be achieved *before* bringing SwellRT would be if
everyone who is interested in contributing headed over to SwellRT, and
started contributing over there. Then, we'd be bringing both code and
community into Apache, which would give me far more confidence than just
importing code but with no confidence that anyone is actually going to
do anything with it.
Upayavira
On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote:
> Pablo, a lot of great information in this slide deck. I hope others have
> a
> chance to review as well. Outstanding work.
>
> Price, very thoughtful responses. I agree with the overall conclusion -
> SwellRT should be brought into Wave.
>
> I like the idea of moving the SwellRT fork in to replace the current
> branch
> of Wave development because it moves the project reasonably forward and
> makes sense overall. It does not seem anything current would be lost in
> that move. It seems like we have everything to gain. However, there
> might
> be work in progress that is affected.
>
> It would be great if contributors on the project took a look and shared
> some thoughts.
>
> Q3) For current contributors; are you in favor of bringing the fork home?
>
> -
> Great attendance at our last meeting, and familiar ground was covered.
> (agenda
> and notes
> <https://docs.google.com/document/d/11j_WQGYAtDlN8Wqx8jJglPpw6tJznvMGfdLOvQu96i0/edit>)
> We're largely covering the next steps in recent emails.
>
> If the group agrees, that we should bring SwellRT into Apache Wave, then
> there needs to be a proposal drafted.
>
> Q4) Does anyone have interest, experience or desire to help with this
> task? We do not expect to start until after the next meeting.
>
> -
> Perhaps 2-3 weeks is time enough to consider the questions posed?
> I'd like to plan our next steps;
> I suggest *10/26 as the next discussion* - based on consensus in the list
> of course.
>
> The goal of the next meeting will be to provide a chance to address any
> questions regarding bringing the projects together. Perhaps this could
> be
> a technically deeper discussion.
>
> Q5) Does anyone have interest in a standing co-work session? Especially
> important would be current contributors. I think this could be a good
> way
> for some on the list that have stalled or reached impasse to begin to
> make
> progress in helping out.
>
> Thanks, everyone for your work and efforts. I believe that if each of us
> does just a little bit over the next few weeks we will continue to see
> the
> progress we need in this project.
>
> Adam John
> (914) 623-8433
> Google+ <http://google.com/+AdamJohn1> | LinkedIn
> <http://mradamjohn.com/>
>
> On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pa...@gmail.com>
> wrote:
>
> > Thanks for your answer Price,
> >
> > I guess we should not delay this discussion...
> >
> > I'd happy to run another call if you think it can move things forward.
> >
> >
> >
> > 2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
> >
> > > Pablo, thanks for the presentation.
> > >
> > > While my qualifications to answer this are 0 getting to listen to
> > > Upayavira talk this week (the last Apache mentor if I'm not mistaken)
> > make
> > > me feel the answers to 1 and 2 are easy to answer.
> > >
> > > 1.) Upayavira communicated very fervently that there just isn't enough
> > > oomph in wave's development. Every year around the time that the
> > retirement
> > > conversation is brought up, activity similar to this starts brewing and
> > > then it all dies down in a few months. From this perspective "Does
> > SwellRT
> > > tackle current Wave problems?" The answer is unequivocally yes, SwellRT
> > is
> > > a more actively maintained fork of Wave and given the slowing/slowed pace
> > > of Wave *a merge with SwellRT is likely the only way to save this
> > project*.
> > >
> > > 2.) I would also like to bring up another point Upayavira made,
> > > "Communities are built around good ideas and bad code." Running with
> > that I
> > > thing that good ideas attract tinkerers and 'people with ideas' that
> > could
> > > eventually become 'contributors with ideas'. In some senses SwellRT
> > > splinters Apache Wave in a way that developers on this mailing list have
> > > been alluding to for a while. The client side code is not well understood
> > > and is definitely in the way of the server. SwellRT has a more general
> > goal
> > > of supplying a server that is capable of powering a front-end like the
> > > original vision of google wave. This means that merging with SwellRT
> > would
> > > force a separation of the client and server and allow for people with
> > > interests in either a front or back end to work in tandem. This seems
> > like
> > > an ingenious way to attract more people; anyone with an interest in the
> > > backend technology OR a way to use said technology in an application
> > could
> > > be a potential contributor. Unless I'm mistaken it seems like SwellRT
> > > offers a set of features that could be classified as a superset of Wave's
> > > features. So, it seems like most or all of SwellRT would be at home in
> > > Wave. Pablo also reasonably stated that he'd prefer to work in one
> > project.
> > >
> > > As for me, as soon as a direction is clear I would love to talk to
> > > someone actively maintaining/writing code so I can help them contribute
> > to
> > > whichever code survives in whatever way possible.
> > >
> >
Re: SwellRT tech overview
Posted by Adam John <aj...@sterlingsolved.com>.
Pablo, a lot of great information in this slide deck. I hope others have a
chance to review as well. Outstanding work.
Price, very thoughtful responses. I agree with the overall conclusion -
SwellRT should be brought into Wave.
I like the idea of moving the SwellRT fork in to replace the current branch
of Wave development because it moves the project reasonably forward and
makes sense overall. It does not seem anything current would be lost in
that move. It seems like we have everything to gain. However, there might
be work in progress that is affected.
It would be great if contributors on the project took a look and shared
some thoughts.
Q3) For current contributors; are you in favor of bringing the fork home?
-
Great attendance at our last meeting, and familiar ground was covered. (agenda
and notes
<https://docs.google.com/document/d/11j_WQGYAtDlN8Wqx8jJglPpw6tJznvMGfdLOvQu96i0/edit>)
We're largely covering the next steps in recent emails.
If the group agrees, that we should bring SwellRT into Apache Wave, then
there needs to be a proposal drafted.
Q4) Does anyone have interest, experience or desire to help with this
task? We do not expect to start until after the next meeting.
-
Perhaps 2-3 weeks is time enough to consider the questions posed?
I'd like to plan our next steps;
I suggest *10/26 as the next discussion* - based on consensus in the list
of course.
The goal of the next meeting will be to provide a chance to address any
questions regarding bringing the projects together. Perhaps this could be
a technically deeper discussion.
Q5) Does anyone have interest in a standing co-work session? Especially
important would be current contributors. I think this could be a good way
for some on the list that have stalled or reached impasse to begin to make
progress in helping out.
Thanks, everyone for your work and efforts. I believe that if each of us
does just a little bit over the next few weeks we will continue to see the
progress we need in this project.
Adam John
(914) 623-8433
Google+ <http://google.com/+AdamJohn1> | LinkedIn <http://mradamjohn.com/>
On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pa...@gmail.com> wrote:
> Thanks for your answer Price,
>
> I guess we should not delay this discussion...
>
> I'd happy to run another call if you think it can move things forward.
>
>
>
> 2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
>
> > Pablo, thanks for the presentation.
> >
> > While my qualifications to answer this are 0 getting to listen to
> > Upayavira talk this week (the last Apache mentor if I'm not mistaken)
> make
> > me feel the answers to 1 and 2 are easy to answer.
> >
> > 1.) Upayavira communicated very fervently that there just isn't enough
> > oomph in wave's development. Every year around the time that the
> retirement
> > conversation is brought up, activity similar to this starts brewing and
> > then it all dies down in a few months. From this perspective "Does
> SwellRT
> > tackle current Wave problems?" The answer is unequivocally yes, SwellRT
> is
> > a more actively maintained fork of Wave and given the slowing/slowed pace
> > of Wave *a merge with SwellRT is likely the only way to save this
> project*.
> >
> > 2.) I would also like to bring up another point Upayavira made,
> > "Communities are built around good ideas and bad code." Running with
> that I
> > thing that good ideas attract tinkerers and 'people with ideas' that
> could
> > eventually become 'contributors with ideas'. In some senses SwellRT
> > splinters Apache Wave in a way that developers on this mailing list have
> > been alluding to for a while. The client side code is not well understood
> > and is definitely in the way of the server. SwellRT has a more general
> goal
> > of supplying a server that is capable of powering a front-end like the
> > original vision of google wave. This means that merging with SwellRT
> would
> > force a separation of the client and server and allow for people with
> > interests in either a front or back end to work in tandem. This seems
> like
> > an ingenious way to attract more people; anyone with an interest in the
> > backend technology OR a way to use said technology in an application
> could
> > be a potential contributor. Unless I'm mistaken it seems like SwellRT
> > offers a set of features that could be classified as a superset of Wave's
> > features. So, it seems like most or all of SwellRT would be at home in
> > Wave. Pablo also reasonably stated that he'd prefer to work in one
> project.
> >
> > As for me, as soon as a direction is clear I would love to talk to
> > someone actively maintaining/writing code so I can help them contribute
> to
> > whichever code survives in whatever way possible.
> >
>
Re: SwellRT tech overview
Posted by Pablo Ojanguren <pa...@gmail.com>.
Thanks for your answer Price,
I guess we should not delay this discussion...
I'd happy to run another call if you think it can move things forward.
2016-10-01 18:40 GMT+02:00 Price Clark <gp...@gmail.com>:
> Pablo, thanks for the presentation.
>
> While my qualifications to answer this are 0 getting to listen to
> Upayavira talk this week (the last Apache mentor if I'm not mistaken) make
> me feel the answers to 1 and 2 are easy to answer.
>
> 1.) Upayavira communicated very fervently that there just isn't enough
> oomph in wave's development. Every year around the time that the retirement
> conversation is brought up, activity similar to this starts brewing and
> then it all dies down in a few months. From this perspective "Does SwellRT
> tackle current Wave problems?" The answer is unequivocally yes, SwellRT is
> a more actively maintained fork of Wave and given the slowing/slowed pace
> of Wave *a merge with SwellRT is likely the only way to save this project*.
>
> 2.) I would also like to bring up another point Upayavira made,
> "Communities are built around good ideas and bad code." Running with that I
> thing that good ideas attract tinkerers and 'people with ideas' that could
> eventually become 'contributors with ideas'. In some senses SwellRT
> splinters Apache Wave in a way that developers on this mailing list have
> been alluding to for a while. The client side code is not well understood
> and is definitely in the way of the server. SwellRT has a more general goal
> of supplying a server that is capable of powering a front-end like the
> original vision of google wave. This means that merging with SwellRT would
> force a separation of the client and server and allow for people with
> interests in either a front or back end to work in tandem. This seems like
> an ingenious way to attract more people; anyone with an interest in the
> backend technology OR a way to use said technology in an application could
> be a potential contributor. Unless I'm mistaken it seems like SwellRT
> offers a set of features that could be classified as a superset of Wave's
> features. So, it seems like most or all of SwellRT would be at home in
> Wave. Pablo also reasonably stated that he'd prefer to work in one project.
>
> As for me, as soon as a direction is clear I would love to talk to
> someone actively maintaining/writing code so I can help them contribute to
> whichever code survives in whatever way possible.
>