On Tue, Mar 9, 2010 at 2:11 PM, AndrewL <[email protected]> wrote:

> The FedOne ClientBackend provides a means to subscribe to inbound
> update operations.  These appear to be every single server operation
> even if operations originated by that client - let's call these "echo
> operations".
>

That's a symptom of the feature-poor FedOne client, and I think that's
the underlying cause of come of your issues.

> I can see that these echo operations would be useful if I was not
> applying my local edits to a local model, but in my case I am applying
> the ops to the local model as edits are made, simultaneously I
> generate the outbound ops.
>

You need to use a different backend. From a conceptual point of view,
think of your client as another server, just coming through a
different interface instead of the XMPP one. If you look into that
code path, you'll see behaviour much closer to what I described.

> In (9: Feb 3) you make this point:
> "Key point 2: Any operations generated while waiting for a server
> response need to be tracked, because they might get transformed!"
>
> but does this idea also apply to operations that were sent in that
> server submission? as these operations are going to come back to the
> client as "echos".
>

They shouldn't be echoed back at all unless you specifically request
them as part of a recovery or resync operation. The problem is the
interface, not your understanding.

>
> Or is my mistake that I should not apply desired operations to my
> local model as they are made - I must wait for the server to formalise
> these operations?  If this is the case, it makes the idea of building
> an optimistic client quite a lot more difficult
>

Building an optimistic client should be easy enough, but you will need
to use a different backend. FedOne only provides enough of an
interface to support a pessimistic client. You want to either use or
adapt the backend being used to talk to other servers as that has far
more useful logic. Client deltas don't have to come over XMPP, and
they don't have to be signed, but all the other code is perfectly
applicable with an optimistic client.

-- 
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.

Reply via email to