The reason why use cases are not popping up all over the place is precisely because wave is (conceptually) untethered. We as developers love the notion of all or not at all, which is why participants on a wave have almost carte blanch in terms of editing blips and adding whatever extensions they wish. The problem is that this fits so few use cases, and this is not simply a cultural problem. The fact of the matter is small groups, who are already used to working collaboratively in this way, is about it...besides the dreams of some developers and wikis. Without focus we will understandably develop 'cool stuff' in the hope that it will eventually become useful.
Wave has so much more potential and it is the lack access control that is holding it back. However I am glad of the fact it is this way it, because it gives the most flexible staring point. Roles and permission are the one of most unique part of any use case. Come up with a blanket standard and you are going to have many disappointed punters. Explaining wave to complete novices isn't smart. Apart from being confusing and underwhelming to many of them, most of them don't fit into that implied use case as much as you might try to force it. The best thing to do is to bring them to it in a familiar way and meet their expatiations, then allow them to choose to collaborate more 21st century way when wish (such as sharing a blip). My idea is to have something like the robot protocol, and only one extra access case (Public Via Proxy) to cover all other all the possibilities. This special robot/agent is only added once at the beginning and is a condition of publication. It will decide on when blip can be edited, and so forth. Then is done before not after, in other words submission is proxied. The benefit of this system is nobody has to add one it just don't get published by the organisation if they don't want it to. It could added for sub wavelets. Even you could have several of them for slightly different use cases such as one for general community discussion, and another one for collaborating on events and so on. Now the downside. As somebody pointed out, robots are slow. Ideally this would be more agent than robot. The question is whether to go with a distributed agent solution or not with regards to federation? If so there would need to be a protocol for that, otherwise one provider would do the work. However consider the alternative->trying to second guess what solutions people will want. That would be a lot more work and never pleasing everyone. One of the thing that I see as inevitable if nothing is done, is that organisations will be drawing up convoluted federation agreements/ terms and closed infrastructure to match, which is very much against the spirit of federation. Whereas PvP type of solution would mean the federation remains easy and open. No one has to publish what they don't want to anyway, but why impede things with a closed door policy? The idea that wave is like a conversation is actually false. It has some feature in common, but wave is like nothing else. But it has the potential to fit many things...just not as is. >From more info see googlewave.com!w+RTIBOfxLA -- 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.
