On Oct 13, 9:52 am, Stefan Langer <[email protected]> wrote: > But isn't creating a library basically the same as defining the client > server protocol on a different abstraction layer? You do have a indirection > but if the library gets accepted it is likely that it will influence all > future development of a independent C/S protocol.
Yes and no. It does define a particular form of interaction with the client by virtue of its API. But in my experience APIs tend to be simpler than protocols and easier to evolve and modify after the first version is defined. What I'm hoping for is something that would work at a higher level such as perhaps the document model, which is already well known (even if not finalzed yet). One can always add lower-level APIs later if necessary. > What if the library is too Java specific and cannot be easily translated > into different languages resulting in a protocol that is not general enough? Right now I don't really expect it to be translated, because at this stage I'm hoping to only need to split the existing code into two pieces and maybe put some higher-level wrapper around one of those pieces. As far as the wire protocol etc, I'll just be using whatever the current code uses, give or take some abstraction so that it can be replaced later as needed without affecting the API. For a proper translation, you would either need to use the same wire protocol, or wait for a better protocol to be established. I don't know if it's possible to link non-java code against a java library. I'll have to check. That said, this is a good point, and I'll try to keep it in mind. The truth is, I haven't even had a chance to look at the code yet. So this is all just guesswork and wishful thinking at the moment. > I think if you want interoperational clients you need to define a protocol > first. > Keep in mind that a protocol is far more then just the wire format of the > messages passed along. As I said, I'm aiming for a higher level API at this point, with the intention that it should be sufficiently decoupled from the C/S protocol that the protocol can be changed without affecting the API (much). Of course, a true C/S protocol would still be needed, but at least we'll have another option until that is ready. > Another question why are you so sure that Google will include this library > code? Are you in any way associated with the wave development team? I'm not. But this is open source, and there are official guidelines for submitting code. So I see no reason why it should not be accepted if it's written well and is beneficial to the project. Again, do notice the ifs ;-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
