@brian: Small changes are also easier to review, so yes, definitely. I agree that the api split into server/client/common should be done as early as possible. But the abstract base classes for the client's back and front ends need to be done first, otherwise the api is not very useful. I will try to do the split as early as possible - I'll see when it makes sense to do it.
@brett: As I imagine it, you would have an object hierarchy that mirrors the structure of a wave. At each level you would have methods for doing the various operations you can do at that level. For example, you would have a wave object that would have methods for managing the wavelets (getWavelet, createWavelet, etc). Then you would have a wavelet object with methods for whatever you can do to a wavelet (delete, addParticipant, removeParticipant, addBlip, ...). And so on. The document model that's already implemented in FedOne is a good start, but it needs to be cleaned up to improve its encapsulation and abstraction properties. Or maybe this can be done through a new layer that would sit on top of it, since I think it's designed to be low- level. Working with the DocOps can be useful sometimes, but most of the time you shouldn't need to worry about it. You would just call "addText" or "deleteText" or whatever you need to do. -- 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.
