"Jack of All Trades, Master of None". This is a common assumption. What I agree on is it didn't meet expectations in in it current form was not usable (just because seasoned users can use it in chrome doesn't mean it is usable, seasoned geeks aren't always the best judge), and was essentially always going to fail, because it was a a rough diamond, and largely entwined in a subculture (firefly). Although that was sort of an in joke that was really at the heart of the issue. There isn't another Google product I can think of that doesn't have in the name what it is for. The team were naive in thinking that it would somehow magically find it way, and they should have had help developing into a nieche implementation and directly targeting a specific type of use. Only then can you build on that. A wize person once said ther is no such things and the "mass market". You have to start somewhere.
However Wave as a concept isn't so much a replacement email. it is more significant than that, it is more on the level that the internet is in relation to the telegram. But a lot needs to be worked out first. "Wave" should not be uttered outside circles developing wave service or client. That isn't relevant to the user base. What is important is it improves the way they do things. There need to be an intuition to using it, but an enhancement as well. Another reason why it failed is ironically it was limited by it own freedom. It is typecast into a use which at worst is dubious because of the limited Access Controll. However I also agree that just putting a bunch of arbitrary AC setting could actually make things worse, because you are potentially limiting how it might be used in the future. I had some really blue sky ideas public via proxy with publishing agents, etc to try and provide a more ad hock approach to what wavelet interaction actually means for a user. of course this is not a trivial thing, it has to federate, and federate simply without without the need for stipulation, and also it can't afford to be too slow for the users. Also how much to do on trust? One the idea to speed thing up is to have distributed agents, which would be a condition of publication for that federation (there can only be one PvP agent added by whoever creates the wave), in other words if someone doesn't include that publishing agent they can still federate with that service (that uses publishing agents), however the service doest have to publish it in whatever form, nor has to take pride of place within the concept of that wave service concept. Publishing agents allow wave to be meaningful within a specific context. because users do actually have certain exceptions within a specific context and it is not always free for all. if a service provider, doesn't distribute in good faith, then you can always decide not to federate with them. Publishing agent versions could have a checksum. The original issuer may chose to update and this will be distributed to replace the existing agent version. Perhaps a more egalitarian or flexible way needs to be worked out in some instances. RPC is all well and good. But you may want to be able to distribute something that will run as an agent for the wave in a sandbox environment, it takes the weight off a single service provider, and is faster for the participants. How do you decide what form this would be distributed in. Well it could be javascript after all this is exactly what web apps do to distribute an "agent" of the app to the client (browser). So it is not really that far removed to distrubute agent to wave providers. Some agent don't need to be distributed such as "spelly", that is a luxury or considered part of the interface. However the idea of publishing agents is as above make sure interaction works as expected for that context. This in itself will increase the use cases for wave, and the inflexibility born out of freedom has definitely been a stumbling block of wave. -- 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.
