>I disagree. Implementations come before standards, at least if you want the >standard to be workable. IETF standardisation >requires multiple independent >implementations before an RFC can be accepted."
How would the Wave federation itself work if that was required? You cant have a server/sever communication set up without standard for communication. I dont see why we have to have multiple groups doing their own thing here before Google can decide to support a c/s one. All that would mean is a lot of wasted efforts by developers here. I do agree in many case's you need multiple people doing their own thing before "the best" emerges. But in this case theres lots of things that simply cant get done and wont take of untill *something* is agreed upon. And despite this huge thread and multiple waves, not much progress is being made on this discussion from what I see. I dont think anything made will be perfect first time, but we do need to start somewhere. At the very very least Google really should document their own protobuffer method of c/s communication and have some reassurance that it wont change much. (unless, of course, they dont want other clients for their Wave server...which would be fine, but its something they should announce so we dont waste our efforts) >To make a client you need a matching server. And truth be told, building the >server teaches you a lot about how the protocol >works, which is kinda nice >knowledge to have when building the client... I do agree with that, but its only really practical for everyone given unlimited resources and unlimited time. But most of us dont have that. Id also much rather follow a protocol made by someone with the skills and knowledge to do so then to design my own. If Wave is to succeed and flourish and have multiple use's, we cant expect developers to all have to make end-to-end solutions. Indeed, the more work there is for development teams to do on their own, the less polish and experiments they can do with their own bit. For my personal case, if wasn't for the Pygowave guys, my group would be completely stuck in our project. We appreciate their incredibly work and how far ahead they are compared to everyone else here....but we dont want to depend on them. We dont want to make a Pygo-specific client. Untill theres a c/s standard it seems your only going to encourage lots of "server-specific" clients. And that seems very detrimental to the development of the wave community as a whole. >> But the core is identical. A set of documents, and edits on those documents, > kept in sync. Indeed. I was just trying to nip in the bud some points about "not knowing what we want from the protocol" I saw above. > > On Thu, Dec 31, 2009 at 10:30 PM, Thomas Wrobel <[email protected]> wrote: >> >> But for people that dont want to make web based clients, theres not >> much they can do without a standard. > > I disagree. Implementations come before standards, at least if you want the > standard to be workable. IETF standardisation requires multiple independent > implementations before an RFC can be accepted. > >> >> Any efforts they do would need to be added onto either making their >> own server implementation or supporting only one server that has a >> documented c/s spec. (which seems to be only Pygowave). >> Now, sure, we will be abstracting our c/s communication so that we can >> change it later, but its still akin to making an email client before >> POP3/IMAP exists. > > To make a client you need a matching server. And truth be told, building the > server teaches you a lot about how the protocol works, which is kinda nice > knowledge to have when building the client... > >> >> All the c/s needs to do is basicaly the same stuff a s/s needs to do >> minus a few bits. >> Allow a client to login, retrieve all the data it wants from a wave, >> and post blips/new waves. (and preferably give notification back when >> new blips are posted...depending on client this might not be possible, >> but the ability in the protocol should be there.) > > At it's simplest level, operational transforms enable synchronisation of a > distributed structured document. In this respect, the server and the client > are identical, they both need to be able to fold in edits in the form of > DocOps. The major differences between the server and the client is what they > do with the documents. The client renders the document to a user, and > generates edits when the user does something to the document. The server is > responsible for folding in the stream of edits from all of it's clients. Oh, > and persistence. > > But the core is identical. A set of documents, and edits on those documents, > kept in sync. > >> >> We certainly are still figuring out what we can do with Wave....but we >> will be for many years! >> But thats no reason not to have some c/s standard. :( > > The core of any c/s standard for wave clients is going to be DocOps. > Everything after that is just icing, really. > > >> >> 2009/12/31 Brett Morgan <[email protected]>: >> > I'll be honest, I think going for a spec this early in the game is >> > premature. Let's push the envelope on what we can do on top of this >> > infrastructure, then standardise once we have a clue about what we are >> > attempting to do. At this point we're still figuring out what we can do >> > with >> > this baby. >> > >> > On Thu, Dec 31, 2009 at 1:03 PM, Mike Brown <[email protected]> wrote: >> >> >> >> That clause basically says the license is conditional that you're not >> >> making a stream ripper (the wording is vague enough however to be >> >> expanded >> >> to any form of data storage) but looking closer at the spec it's more >> >> multimedia centric than I first thought. Even without the licensing >> >> concerns >> >> it's not the right one to pursue for the spec >> >> >> >> On Wed, Dec 30, 2009 at 3:16 AM, Anthony Baxter >> >> <[email protected]> >> >> wrote: >> >>> >> >>> I don't think it would be possible to use RTMP for Wave, anyway, >> >>> because the license would prohibit it: >> >>> >> >>> http://www.adobe.com/devnet/rtmp/pdf/rtmp_specification_license_1.0.pdf >> >>> says it's only to be used for streaming audio/video. Quite the >> >>> footbullet from Adobe, imho. >> >>> >> >>> (first noted, as far as I am aware, here: >> >>> >> >>> >> >>> http://elliotmurphy.com/2009/12/23/rtmp-license-forbids-anyone-from-storing-data/ >> >>> ) >> >>> >> >>> >> >>> On Wed, Dec 30, 2009 at 10:01, Mike Brown <[email protected]> wrote: >> >>> > Just curious if anyone has looked at adobe's RTMP (recently opened >> >>> > spec) at >> >>> > first glance it looks like it would fit well for what a wave C/S >> >>> > protocol >> >>> > would need. >> >>> > >> >>> > On Sun, Dec 6, 2009 at 6:24 AM, Jo hyphen el <[email protected]> >> >>> > wrote: >> >>> >> >> >>> >> If any dev people don't have preview accounts I have a few >> >>> >> nominations >> >>> >> going spare. send me an email. >> >>> >> >> >>> >> >> >>> >> On Dec 6, 1:15 am, Michael K <[email protected]> wrote: >> >>> >> > Guys, this discussion has moved to wave preview a long time ago. >> >>> >> > Those >> >>> >> > of you who have accounts, can find the relevant waves by >> >>> >> > searching >> >>> >> > "group:[email protected]". >> >>> >> > >> >>> >> >> >>> >> -- >> >>> >> >> >>> >> You received this message because you are subscribed to the Google >> >>> >> Groups >> >>> >> "Wave Protocol" group. >> >>> >> To post to this group, send email to >> >>> >> [email protected]. >> >>> >> To unsubscribe from this group, send email to >> >>> >> [email protected]. >> >>> >> For more options, visit this group at >> >>> >> http://groups.google.com/group/wave-protocol?hl=en. >> >>> >> >> >>> >> >> >>> > >> >>> > -- >> >>> > >> >>> > You received this message because you are subscribed to the Google >> >>> > Groups >> >>> > "Wave Protocol" group. >> >>> > To post to this group, send email to [email protected]. >> >>> > To unsubscribe from this group, send email to >> >>> > [email protected]. >> >>> > For more options, visit this group at >> >>> > http://groups.google.com/group/wave-protocol?hl=en. >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Anthony Baxter, [email protected] >> >>> >> >>> -- >> >>> >> >>> You received this message because you are subscribed to the Google >> >>> Groups >> >>> "Wave Protocol" group. >> >>> To post to this group, send email to [email protected]. >> >>> To unsubscribe from this group, send email to >> >>> [email protected]. >> >>> For more options, visit this group at >> >>> http://groups.google.com/group/wave-protocol?hl=en. >> >>> >> >>> >> >> >> >> -- >> >> >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "Wave Protocol" group. >> >> To post to this group, send email to [email protected]. >> >> To unsubscribe from this group, send email to >> >> [email protected]. >> >> For more options, visit this group at >> >> http://groups.google.com/group/wave-protocol?hl=en. >> > >> > >> > >> > -- >> > Brett Morgan http://domesticmouse.livejournal.com/ >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> > Groups >> > "Wave Protocol" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group at >> > http://groups.google.com/group/wave-protocol?hl=en. >> > >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Wave Protocol" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/wave-protocol?hl=en. >> >> > > > > -- > Brett Morgan http://domesticmouse.livejournal.com/ > > -- > > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
