I'd like to contribute in this discussion since I used FedOne in a thesis for building a collaborative editor for graphical process plans. For this, I also needed to store non text data in federated Wave conversation elements. What I did at that time was using ADTs included in the FedOne code base. I stored data in such ADTs and inserted them into conversation elements. Once understood, this was quite straight forward. By inserting different data into e.g. different conversations (Wavelets) one can easily realize different views at the graphical plan via conversation participation.
The only problems were understanding of the code base and finding a good hook point for the custom GWT front end. I'm not very responsive at the moment (conference) but will be happy to share experiences. Andreas Am 29.11.2011 01:24 schrieb "Christian Ohler" <[email protected]>: > 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. >
