Thank you, Ali, for your thoughtful comments. I have some responses below (which would look much better in Wave :-))
> I would just like to remind people that Apache Wave has had working > federation support in the code base since creation. (Nullifying some > of the points in slides 3,4 and 16). > > The problem is not the lack of federation support in Apache Wave, > rather the lack of a roll-out of its use between currently active Wave > servers. (Which requires the server admins at both ends of a > federation link to make configuration changes). > Beyond reminding people of this feature, I am unsure how we can > increase adoption of it. Suggestions welcome? > My impression from speaking with some developers is that there is definitely room for improvement in the existing federation code - I am not sure if this is the source of failure to implement it in actuality, but doubtless it contributes. Also, what's definitely not covered in the existing code base is mobile-to-mobile-to-Web federation. People need their waves to live on their mobile devices, not just on cloud Web servers. After all, email provides local mobile offline capabilities. So if you are considering the possibility of a mobile-first world, you really do need to rethink existing Wave federation paradigms seriously., > > > I'd like the Apache community to comment for now but I appreciate the > > sentiment. > > Many of these points follow the vision that (I think) we have all held > for Wave, yet on a practical note are stalled for the time when the > codebase is cleanly separated between client and server. (Of which > some work was started about a year ago during the 'mavenisation' of > the codebase, but stalled). [This is probably our most important task > beyond making a 'release']. > Interesting point. Quite possibly well-separated server code could live on, whilst ironing out how to make it as efficient as possible. With a separated client, then the process of implementing it in JS-derived code becomes much easier, and it becomes feasible to do a mobile client/server stack supporting mobile-to-mobile and mobile-to-Web federation, possibly via code using HTML5-based offline capabilites and emerging hardware interface APIs. > > I don't think there are any major issues with making the slides > public, as long as you ensure it is _not_ presented as a view > sponsored or endorsed in any way by Apache or the Apache Wave project. > My understanding is that you also need to add attribution for use of > the logo. (See: http://www.waveprotocol.org/logo). > IANAL though, so it would be best to wait for some of the others to > comment here before making public. > I will add the appropriate attribution. Beyond that, though, I do think that there has to be a more serious consideration why Wave, with its enormous potential, has not made notable commercial progress in four years. It is not just an issue of federation, though that is one key portion, without which email replacement is completely impractical. Certainly the current design's architecture, which does not support message/blip level data typing and multiple UIs accessing the same waves or effective use of apps in offline and mobile modes, also contributes to the slow growth of an apps ecosystem. But the largest factor may be that there is not an organization dedicated to making Wave a commercial adoption success. If one considers Linux, for example, there is a foundation arm, and then an arm which promotes the use of Linux commercially. The Web has moved on, and Wave has not moved substantially, in part because there are no strong forces for keeping it up to date in ways that will encourage commercial use. So I do think that there is an opportunity for ASF to consider how that might be able to be realized for Wave. Its conversational data model and potential for independent data ownership across multiple UIs and apps should be right in the thick of everything that's happening in the cloud and in the mobile Web. Thank you again, I look forward to continuing the conversation. Best, John Blossom > > Ali >
