On 29 November 2011 01:23, Christian Ohler <[email protected]> wrote: > On Mon, Nov 28, 2011 at 15:26, Thomas Wrobel <[email protected]> wrote: >> On 28 November 2011 22:35, Christian Ohler <[email protected]> wrote: >>> On Mon, Nov 28, 2011 at 12:19, Thomas Wrobel <[email protected]> wrote: >>>> We always were keen to keep federation though, as well as having some >>>> sort of fallback view for standard wave clients. (for example, a >>>> gadget that displays then geolocated objects on google map rather then >>>> the AR view on phones). Without federation we felt our idea would >>>> essentially be no better then what company's like Layar or Wikitude >>>> already offer - we wanted the ability for anyone to independently >>>> publish their own feeds of data without any other company being in >>>> control of that feed. >>> >>> That doesn't sound like it requires federation. If all you want is >>> publish feeds (that are owned by the publisher and read-only to >>> everyone else), you can get away with a much simpler solution. >>> >> >> It does if you want the feeds to allow private or "selective" >> publishing, which we did. >> >> You cant really have an authentication system that allows only some >> people to see some stuff without a server that keeps track of those >> permissions and the IDs tied to them. If you then want anyone to be >> able to start a server, you need federation in order for people on one >> server to see (private) content from another server. > > Wave's federation protocol is more than that, though. The crypto and > other parts of the protocol that allows parties that don't trust each > other to contribute to the same wavelet are unnecessary for your > application as far as I can see. This is why I think a much simpler > protocol would suffice here.
Wave does do more then I need indeed. But I'm not aware of any other protocol that allows federated, persistent realtime updating and selectively publishing of information to certain people. (and given how hard it is to make wave a success a new, incompatible sub-set of waves ability's doesn't seem to stand much hope. I don't think two revil federations would help anyone). I also think having many groups contribute to the same wavelet is also pretty useful for many types of data. For example, you could have collaborative 3d modelling between a few architects working on a city project. I guess in this scenario they would all be "trusted" though. What would be most usefull would be having full read/write permissions. Then you could have projects were some are able to view, but not edit. So 3D art could be editable in a private group, but viewable by anyone at the same time as its being made. This is getting ahead of the current state of even Apache Wave though. Either way, theres lots of quite interesting possibilities I see with WFP that I dont see with other protocols at the moment. -Thomas
