I haven't had any free time in a while but i'd love to take a closer look at walkaround and its slob model. You could probably do something like you want on top of the slob model. You could even share js core for your custom OT and use Rhino to interpret it on the server side. No dia 28 de Nov de 2011 22:37, "Michael MacFadden" < [email protected]> escreveu:
> 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. > >
