Re: Wave and Incubation
I've been interested on Wave since almost one year, first as Kune contributor and lately in a separated project trying to reuse Wave technology in general way. I agree, the issue is the lack of separation between server and client and other components, the handicap to develop on top of Wave unless you have a deep knowledge and its focus on a final product (Conversations). I will keep working on Wave, because* it's the only federated alternative for real-time collaboration* and it is a good technology. These are my current projects extending Wave, of course, anyone is invited to participate: *https://github.com/P2Pvalue/incubator-wave https://github.com/P2Pvalue/incubator-wave *A JavaScript API to manage general Wave content: maps, lists and strings (kind of Google Drive Real-Time API). *https://github.com/Zorbel/swell-android* https://github.com/Zorbel/swell-android Experimental port of the Wave Client (without IU) code to Android. The aim is to provide the previous API in Android. I regret this situation. Thank you 2015-03-15 12:09 GMT+01:00 Francesco Rossi f...@schermaontc.com: Yuri suggested me in PVT some interesting open alternatives although I think they would still lack the options that Wave has. Just to name 2 of them: share.js rizzoma of course they have different functions, but at least they would share some Wave dna. the point is that coding on top of those solutions seemed a lot of work just to catch up with the features Wave has. but I'd be glad to be disputed at this point. Still, I'm a bit perplexed about the client/server conversation. I looked around and just for example, Splash is an old client but looked like it was quite split from the server architecture. What am I missing? On 3/15/2015 3:51 AM, Bruce Hellstrom wrote: The problem is technology keeps marching on while the wave project has remained mostly stagnant. I wanted to setup an internal wave server at our company and try to get it adopted as the company standard for our communications. I hate trying to manage email threads that get so long and disjointed. Wave was such a good solution. I wanted to wait until the db storage of waves support was put in, which is there now I believe. However, the company has started using Slack and I have to say it's hard to argue against that with a beta of Wave in it's current state. Slack has a lot of the features I was looking for in wave as well as clients that work on almost all mobile devices now. The downside is, the data storage resides with Slack and not on our own internal company servers, but that doesn't seem to be an issue. I think Wave is still an awesome product that was ahead of it's time, but now it would just take too much effort to bring it up-to-date. It needs to support all the latest incarnations of the browsers, which is a moving target now that almost all are on fast release cycles. It needs full mobile support apps. I just don't think there's enough people who have enough time to devote to all that needs to be done. On 03/15/2015 03:23 AM, Francesco Rossi wrote: Guys, I'm a newbie too and we are thinking of building an entire app over wave. It sounds really bat that the community is willing to give up. On 3/15/2015 3:14 AM, ujadatron wrote: It sounds bad. I'm a few days newbee in this mailing list. (I'm looking for a flexible open source collaboration framework). Do you suggest any of them? (if the Wave will retire) thanks in advance adatron 2015.03.14. 22:28 keltezéssel, James Keener írta: I was going to write almost exactly the same email and decided not to. I found wave and wanted to use it, but it's dependence on the GWT and how intertwined the Client and Server were made it very difficult for me to understand and I moved to share.js because I could more easily comprehend it's inner workings and could build my client around it. Ideally two projects and a documented protocol would have been best. Much like how email severs and clients can be developed separately, and standards like pop3 and imap used to talk between them. This would have been ideal I feel. I've seen multiple people on this mailing list asking how to integrate with the server and there is never a good response. Jim On 03/14/2015 05:18 PM, Thomas Wrobel wrote: I'll just sadly from my little lurker corner repeat what I have been saying for 3 years or so now; I wanted to work on a client, despite trying, I lacked the ability to understand the server side code. There was never a clear separation of client and sever that I feel would have allowed less skilled coders like me to contribute. I was frustrated when I saw GWT/ GUI issues on the web client being posted at times to fix...and I could have helped with that. But I couldn't, because the bureaucracy of having the sever and client tied together made (for me) trivial things rather hard. My half-developed phone client remained dead since
Re: Wave and Incubation
Thanks for that I'll look into both your Javascript API and your Android one. Is your communication between client and server just between your forked one or the standard wave server as well? If your approach is functional and everyone could agree to use it I feel a lot of progress could be made. ~~~ Thomas Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 15 March 2015 at 16:31, Pablo Ojanguren pablo...@gmail.com wrote: I’d like to clarify a bit more my work during the last year and a half, as I think it can respond to the needs that are being raised in this thread: - Wave storage based on Database - Server-Client separation - Reduce code complexity or cover it up - No dependency to GWT / Ability to build clients in modern frontend frameworks - Mobile support I’ve addressed basically all that: - Provided MongoDB storage for Waves - Discarded GWT client and replaced by a JavaScript API. Anyone can build Web apps in new frontend frameworks like AngularJS… - Extended Wave model to support general collaborative content: maps, lists and strings. You can use the Wave to store your own data. - The API is being adapted to work for Android and Java, although still experimental Some of them have been added to the original Wave project, but others are available in my forked version of Wave: The Wave platform including the general JavaScript API: https://github.com/P2Pvalue/incubator-wave Experimental port of the Wave API to Android: https://github.com/Zorbel/swell-android I will keep contributing to Wave... 2015-03-15 16:24 GMT+01:00 Thomas Wrobel darkfl...@gmail.com: Splash is an old client but looked like it was quite split from the server architecture. What am I missing? That its almost certainly not compatible with the current Wave sever code. Back when it was Google wave there was 4-5 clients, including prototype mobile ones. All died pretty soon after the transfer to Apache. I admit I havnt checked on Splash recently though, if its had a update in the past year to make it compatible again I wouldn't know. On 15 March 2015 at 12:09, Francesco Rossi f...@schermaontc.com wrote: Yuri suggested me in PVT some interesting open alternatives although I think they would still lack the options that Wave has. Just to name 2 of them: share.js rizzoma of course they have different functions, but at least they would share some Wave dna. the point is that coding on top of those solutions seemed a lot of work just to catch up with the features Wave has. but I'd be glad to be disputed at this point. Still, I'm a bit perplexed about the client/server conversation. I looked around and just for example, Splash is an old client but looked like it was quite split from the server architecture. What am I missing? On 3/15/2015 3:51 AM, Bruce Hellstrom wrote: The problem is technology keeps marching on while the wave project has remained mostly stagnant. I wanted to setup an internal wave server at our company and try to get it adopted as the company standard for our communications. I hate trying to manage email threads that get so long and disjointed. Wave was such a good solution. I wanted to wait until the db storage of waves support was put in, which is there now I believe. However, the company has started using Slack and I have to say it's hard to argue against that with a beta of Wave in it's current state. Slack has a lot of the features I was looking for in wave as well as clients that work on almost all mobile devices now. The downside is, the data storage resides with Slack and not on our own internal company servers, but that doesn't seem to be an issue. I think Wave is still an awesome product that was ahead of it's time, but now it would just take too much effort to bring it up-to-date. It needs to support all the latest incarnations of the browsers, which is a moving target now that almost all are on fast release cycles. It needs full mobile support apps. I just don't think there's enough people who have enough time to devote to all that needs to be done. On 03/15/2015 03:23 AM, Francesco Rossi wrote: Guys, I'm a newbie too and we are thinking of building an entire app over wave. It sounds really bat that the community is willing to give up. On 3/15/2015 3:14 AM, ujadatron wrote: It sounds bad. I'm a few days newbee in this mailing list. (I'm looking for a flexible open source collaboration framework). Do you suggest any of them? (if the Wave will retire) thanks in advance adatron 2015.03.14. 22:28 keltezéssel, James Keener írta: I was going to write almost exactly the same email and decided not to. I
Re: Wave and Incubation
I’d like to clarify a bit more my work during the last year and a half, as I think it can respond to the needs that are being raised in this thread: - Wave storage based on Database - Server-Client separation - Reduce code complexity or cover it up - No dependency to GWT / Ability to build clients in modern frontend frameworks - Mobile support I’ve addressed basically all that: - Provided MongoDB storage for Waves - Discarded GWT client and replaced by a JavaScript API. Anyone can build Web apps in new frontend frameworks like AngularJS… - Extended Wave model to support general collaborative content: maps, lists and strings. You can use the Wave to store your own data. - The API is being adapted to work for Android and Java, although still experimental Some of them have been added to the original Wave project, but others are available in my forked version of Wave: The Wave platform including the general JavaScript API: https://github.com/P2Pvalue/incubator-wave Experimental port of the Wave API to Android: https://github.com/Zorbel/swell-android I will keep contributing to Wave... 2015-03-15 16:24 GMT+01:00 Thomas Wrobel darkfl...@gmail.com: Splash is an old client but looked like it was quite split from the server architecture. What am I missing? That its almost certainly not compatible with the current Wave sever code. Back when it was Google wave there was 4-5 clients, including prototype mobile ones. All died pretty soon after the transfer to Apache. I admit I havnt checked on Splash recently though, if its had a update in the past year to make it compatible again I wouldn't know. On 15 March 2015 at 12:09, Francesco Rossi f...@schermaontc.com wrote: Yuri suggested me in PVT some interesting open alternatives although I think they would still lack the options that Wave has. Just to name 2 of them: share.js rizzoma of course they have different functions, but at least they would share some Wave dna. the point is that coding on top of those solutions seemed a lot of work just to catch up with the features Wave has. but I'd be glad to be disputed at this point. Still, I'm a bit perplexed about the client/server conversation. I looked around and just for example, Splash is an old client but looked like it was quite split from the server architecture. What am I missing? On 3/15/2015 3:51 AM, Bruce Hellstrom wrote: The problem is technology keeps marching on while the wave project has remained mostly stagnant. I wanted to setup an internal wave server at our company and try to get it adopted as the company standard for our communications. I hate trying to manage email threads that get so long and disjointed. Wave was such a good solution. I wanted to wait until the db storage of waves support was put in, which is there now I believe. However, the company has started using Slack and I have to say it's hard to argue against that with a beta of Wave in it's current state. Slack has a lot of the features I was looking for in wave as well as clients that work on almost all mobile devices now. The downside is, the data storage resides with Slack and not on our own internal company servers, but that doesn't seem to be an issue. I think Wave is still an awesome product that was ahead of it's time, but now it would just take too much effort to bring it up-to-date. It needs to support all the latest incarnations of the browsers, which is a moving target now that almost all are on fast release cycles. It needs full mobile support apps. I just don't think there's enough people who have enough time to devote to all that needs to be done. On 03/15/2015 03:23 AM, Francesco Rossi wrote: Guys, I'm a newbie too and we are thinking of building an entire app over wave. It sounds really bat that the community is willing to give up. On 3/15/2015 3:14 AM, ujadatron wrote: It sounds bad. I'm a few days newbee in this mailing list. (I'm looking for a flexible open source collaboration framework). Do you suggest any of them? (if the Wave will retire) thanks in advance adatron 2015.03.14. 22:28 keltezéssel, James Keener írta: I was going to write almost exactly the same email and decided not to. I found wave and wanted to use it, but it's dependence on the GWT and how intertwined the Client and Server were made it very difficult for me to understand and I moved to share.js because I could more easily comprehend it's inner workings and could build my client around it. Ideally two projects and a documented protocol would have been best. Much like how email severs and clients can be developed separately, and standards like pop3 and imap used to talk between them. This would have been ideal I feel. I've seen multiple people on this mailing list asking how to integrate with the server and
Re: Wave and Incubation
Splash is an old client but looked like it was quite split from the server architecture. What am I missing? That its almost certainly not compatible with the current Wave sever code. Back when it was Google wave there was 4-5 clients, including prototype mobile ones. All died pretty soon after the transfer to Apache. I admit I havnt checked on Splash recently though, if its had a update in the past year to make it compatible again I wouldn't know. On 15 March 2015 at 12:09, Francesco Rossi f...@schermaontc.com wrote: Yuri suggested me in PVT some interesting open alternatives although I think they would still lack the options that Wave has. Just to name 2 of them: share.js rizzoma of course they have different functions, but at least they would share some Wave dna. the point is that coding on top of those solutions seemed a lot of work just to catch up with the features Wave has. but I'd be glad to be disputed at this point. Still, I'm a bit perplexed about the client/server conversation. I looked around and just for example, Splash is an old client but looked like it was quite split from the server architecture. What am I missing? On 3/15/2015 3:51 AM, Bruce Hellstrom wrote: The problem is technology keeps marching on while the wave project has remained mostly stagnant. I wanted to setup an internal wave server at our company and try to get it adopted as the company standard for our communications. I hate trying to manage email threads that get so long and disjointed. Wave was such a good solution. I wanted to wait until the db storage of waves support was put in, which is there now I believe. However, the company has started using Slack and I have to say it's hard to argue against that with a beta of Wave in it's current state. Slack has a lot of the features I was looking for in wave as well as clients that work on almost all mobile devices now. The downside is, the data storage resides with Slack and not on our own internal company servers, but that doesn't seem to be an issue. I think Wave is still an awesome product that was ahead of it's time, but now it would just take too much effort to bring it up-to-date. It needs to support all the latest incarnations of the browsers, which is a moving target now that almost all are on fast release cycles. It needs full mobile support apps. I just don't think there's enough people who have enough time to devote to all that needs to be done. On 03/15/2015 03:23 AM, Francesco Rossi wrote: Guys, I'm a newbie too and we are thinking of building an entire app over wave. It sounds really bat that the community is willing to give up. On 3/15/2015 3:14 AM, ujadatron wrote: It sounds bad. I'm a few days newbee in this mailing list. (I'm looking for a flexible open source collaboration framework). Do you suggest any of them? (if the Wave will retire) thanks in advance adatron 2015.03.14. 22:28 keltezéssel, James Keener írta: I was going to write almost exactly the same email and decided not to. I found wave and wanted to use it, but it's dependence on the GWT and how intertwined the Client and Server were made it very difficult for me to understand and I moved to share.js because I could more easily comprehend it's inner workings and could build my client around it. Ideally two projects and a documented protocol would have been best. Much like how email severs and clients can be developed separately, and standards like pop3 and imap used to talk between them. This would have been ideal I feel. I've seen multiple people on this mailing list asking how to integrate with the server and there is never a good response. Jim On 03/14/2015 05:18 PM, Thomas Wrobel wrote: I'll just sadly from my little lurker corner repeat what I have been saying for 3 years or so now; I wanted to work on a client, despite trying, I lacked the ability to understand the server side code. There was never a clear separation of client and sever that I feel would have allowed less skilled coders like me to contribute. I was frustrated when I saw GWT/ GUI issues on the web client being posted at times to fix...and I could have helped with that. But I couldn't, because the bureaucracy of having the sever and client tied together made (for me) trivial things rather hard. My half-developed phone client remained dead since Googles time as well because I couldn't figure out how to interface with the changes made to how you should talk to the sever. I had at one point 3 people helping me on that project, and with a client/sever protocol we could have all contributed. Ideally two projects and a documented protocol would have been best. Much like how email severs and clients can be developed separately, and standards like pop3 and imap used to talk between them. I fully acknowledge much of this is my own lack of skills, and with everyone unpaid volunteers I cant expect anything.
Re: Wave and Incubation
Guys, I'm a newbie too and we are thinking of building an entire app over wave. It sounds really bat that the community is willing to give up. On 3/15/2015 3:14 AM, ujadatron wrote: It sounds bad. I'm a few days newbee in this mailing list. (I'm looking for a flexible open source collaboration framework). Do you suggest any of them? (if the Wave will retire) thanks in advance adatron 2015.03.14. 22:28 keltezéssel, James Keener írta: I was going to write almost exactly the same email and decided not to. I found wave and wanted to use it, but it's dependence on the GWT and how intertwined the Client and Server were made it very difficult for me to understand and I moved to share.js because I could more easily comprehend it's inner workings and could build my client around it. Ideally two projects and a documented protocol would have been best. Much like how email severs and clients can be developed separately, and standards like pop3 and imap used to talk between them. This would have been ideal I feel. I've seen multiple people on this mailing list asking how to integrate with the server and there is never a good response. Jim On 03/14/2015 05:18 PM, Thomas Wrobel wrote: I'll just sadly from my little lurker corner repeat what I have been saying for 3 years or so now; I wanted to work on a client, despite trying, I lacked the ability to understand the server side code. There was never a clear separation of client and sever that I feel would have allowed less skilled coders like me to contribute. I was frustrated when I saw GWT/ GUI issues on the web client being posted at times to fix...and I could have helped with that. But I couldn't, because the bureaucracy of having the sever and client tied together made (for me) trivial things rather hard. My half-developed phone client remained dead since Googles time as well because I couldn't figure out how to interface with the changes made to how you should talk to the sever. I had at one point 3 people helping me on that project, and with a client/sever protocol we could have all contributed. Ideally two projects and a documented protocol would have been best. Much like how email severs and clients can be developed separately, and standards like pop3 and imap used to talk between them. I fully acknowledge much of this is my own lack of skills, and with everyone unpaid volunteers I cant expect anything. But this is my hypothesis as to why Wave development wasn't as active as it could have been. -Thomas Wrobel arwave.org ~~~ Thomas Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 14 March 2015 at 21:52, Upayavira u...@odoko.co.uk wrote: Wave has been incubating for some years now, and, unfortunately, has not shown a level of growth that, in my opinion, would suggest that it is likely to reach graduation from the Incubator. Unfortunately, I think it is time we accept that Wave is unlikely to reach graduation, and should retire. To explain what this means - as I understand it, the ASF repo would be marked read-only, and after a period of time, the lists disabled. The code would, however, remain open-source, and any person, or group of people would be free to fork the code and continue with it elsewhere, e.g. Github/Sourceforge/etc. In the end, this is a decision of the Incubator PMC, however I’d like to see whether anyone here has any thoughts to add before I put this to the wider Incubator community. Upayavira P.S. This came up on the incubator-general list as a part of a discussion on the Wave report
Re: Wave and Incubation
It sounds bad. I'm a few days newbee in this mailing list. (I'm looking for a flexible open source collaboration framework). Do you suggest any of them? (if the Wave will retire) thanks in advance adatron 2015.03.14. 22:28 keltezéssel, James Keener írta: I was going to write almost exactly the same email and decided not to. I found wave and wanted to use it, but it's dependence on the GWT and how intertwined the Client and Server were made it very difficult for me to understand and I moved to share.js because I could more easily comprehend it's inner workings and could build my client around it. Ideally two projects and a documented protocol would have been best. Much like how email severs and clients can be developed separately, and standards like pop3 and imap used to talk between them. This would have been ideal I feel. I've seen multiple people on this mailing list asking how to integrate with the server and there is never a good response. Jim On 03/14/2015 05:18 PM, Thomas Wrobel wrote: I'll just sadly from my little lurker corner repeat what I have been saying for 3 years or so now; I wanted to work on a client, despite trying, I lacked the ability to understand the server side code. There was never a clear separation of client and sever that I feel would have allowed less skilled coders like me to contribute. I was frustrated when I saw GWT/ GUI issues on the web client being posted at times to fix...and I could have helped with that. But I couldn't, because the bureaucracy of having the sever and client tied together made (for me) trivial things rather hard. My half-developed phone client remained dead since Googles time as well because I couldn't figure out how to interface with the changes made to how you should talk to the sever. I had at one point 3 people helping me on that project, and with a client/sever protocol we could have all contributed. Ideally two projects and a documented protocol would have been best. Much like how email severs and clients can be developed separately, and standards like pop3 and imap used to talk between them. I fully acknowledge much of this is my own lack of skills, and with everyone unpaid volunteers I cant expect anything. But this is my hypothesis as to why Wave development wasn't as active as it could have been. -Thomas Wrobel arwave.org ~~~ Thomas Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 14 March 2015 at 21:52, Upayavira u...@odoko.co.uk wrote: Wave has been incubating for some years now, and, unfortunately, has not shown a level of growth that, in my opinion, would suggest that it is likely to reach graduation from the Incubator. Unfortunately, I think it is time we accept that Wave is unlikely to reach graduation, and should retire. To explain what this means - as I understand it, the ASF repo would be marked read-only, and after a period of time, the lists disabled. The code would, however, remain open-source, and any person, or group of people would be free to fork the code and continue with it elsewhere, e.g. Github/Sourceforge/etc. In the end, this is a decision of the Incubator PMC, however I’d like to see whether anyone here has any thoughts to add before I put this to the wider Incubator community. Upayavira P.S. This came up on the incubator-general list as a part of a discussion on the Wave report
Re: Wave and Incubation
I think it is helpful that the wave standard be maintained by an established organization like the Apache. Yes, other tools with wave-y features, such as Google Docs, Rizzoma, and Slack, exist, but one of the most exciting promises of Wave was the open protocol for real-time communication and collaboration, and I really want to see that kept alive. Zachary Yaro On 15 March 2015 at 11:46, Thomas Wrobel darkfl...@gmail.com wrote: Thanks for that I'll look into both your Javascript API and your Android one. Is your communication between client and server just between your forked one or the standard wave server as well? If your approach is functional and everyone could agree to use it I feel a lot of progress could be made. ~~~ Thomas Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 15 March 2015 at 16:31, Pablo Ojanguren pablo...@gmail.com wrote: I’d like to clarify a bit more my work during the last year and a half, as I think it can respond to the needs that are being raised in this thread: - Wave storage based on Database - Server-Client separation - Reduce code complexity or cover it up - No dependency to GWT / Ability to build clients in modern frontend frameworks - Mobile support I’ve addressed basically all that: - Provided MongoDB storage for Waves - Discarded GWT client and replaced by a JavaScript API. Anyone can build Web apps in new frontend frameworks like AngularJS… - Extended Wave model to support general collaborative content: maps, lists and strings. You can use the Wave to store your own data. - The API is being adapted to work for Android and Java, although still experimental Some of them have been added to the original Wave project, but others are available in my forked version of Wave: The Wave platform including the general JavaScript API: https://github.com/P2Pvalue/incubator-wave Experimental port of the Wave API to Android: https://github.com/Zorbel/swell-android I will keep contributing to Wave... 2015-03-15 16:24 GMT+01:00 Thomas Wrobel darkfl...@gmail.com: Splash is an old client but looked like it was quite split from the server architecture. What am I missing? That its almost certainly not compatible with the current Wave sever code. Back when it was Google wave there was 4-5 clients, including prototype mobile ones. All died pretty soon after the transfer to Apache. I admit I havnt checked on Splash recently though, if its had a update in the past year to make it compatible again I wouldn't know. On 15 March 2015 at 12:09, Francesco Rossi f...@schermaontc.com wrote: Yuri suggested me in PVT some interesting open alternatives although I think they would still lack the options that Wave has. Just to name 2 of them: share.js rizzoma of course they have different functions, but at least they would share some Wave dna. the point is that coding on top of those solutions seemed a lot of work just to catch up with the features Wave has. but I'd be glad to be disputed at this point. Still, I'm a bit perplexed about the client/server conversation. I looked around and just for example, Splash is an old client but looked like it was quite split from the server architecture. What am I missing? On 3/15/2015 3:51 AM, Bruce Hellstrom wrote: The problem is technology keeps marching on while the wave project has remained mostly stagnant. I wanted to setup an internal wave server at our company and try to get it adopted as the company standard for our communications. I hate trying to manage email threads that get so long and disjointed. Wave was such a good solution. I wanted to wait until the db storage of waves support was put in, which is there now I believe. However, the company has started using Slack and I have to say it's hard to argue against that with a beta of Wave in it's current state. Slack has a lot of the features I was looking for in wave as well as clients that work on almost all mobile devices now. The downside is, the data storage resides with Slack and not on our own internal company servers, but that doesn't seem to be an issue. I think Wave is still an awesome product that was ahead of it's time, but now it would just take too much effort to bring it up-to-date. It needs to support all the latest incarnations of the browsers, which is a moving target now that almost all are on fast release cycles. It needs full mobile support apps. I just don't think there's enough people who have enough time to devote to all that needs to be done. On 03/15/2015 03:23 AM, Francesco Rossi wrote:
