I understand the comment on federation.  Mean that if you have some sort of 
custom data types and or operations supported by the OT engine, then these 
operations would need to be understood by all servers that needed to federate.  
If you implemented a custom OT data model on one server that another server 
didn't know how to handle then federation would work.  However, I have a few 
comments on this:

1)  We are considering a case where a single organization has many servers 
themselves that would be federated.  In this case, all of the servers would 
have the same OT engine capabilities.

2)  We don't need to federate with servers out side of the organization.

3) I would expect that a custom data model would leverage a customer user 
interface component.  So this would need to be installed in any participating 
server anyway.  On thought was to have the OT engine itself be extendable in 
the same way that gadgets are added.  Meaning there could be a way add a custom 
data type to the server on demand.  That way if a wave was federated to you 
from a server, then the receiving server might have a way to get the required 
OT component from the originating server.  Of course this would need to be 
standardized and lots of security concerns analyzed.  But in theory, it could 
be done.


On Nov 28, 2011, at 1:35 PM, Christian Ohler 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.

Reply via email to