Guys, I'm curious what you are thinking for a high level api for documents would look like.
My understanding of the code base, and correct me if I am wrong, is that documents and edits to those documents are expressed in terms of DocOps from the core right out to the agents. The additional infrastructure code is focused on segregating these DocOps into individual documents, handling non document modifications (adding and subtracting participants, signing these edits, and then communicating the edits. I suppose someone could build a facade over DocOpBuilder that was aware of the current document, and thus can enforce that the DocOp under construction will compose when applied, but that's about as far as I can see. What needs to be added above DocOps to make a useful higher level abstraction? brett On Tue, Dec 1, 2009 at 10:22 AM, Michael K <[email protected]> wrote: > > We've tried to keep the console specific code and the protocol/API code > as > > separate as possible (the waveclient.common versus waveclient.console), > but > > it can definitely go further, especially with more separation of the > > document model and a further layer of abstraction w.r.t the UI. Of > course, > > it's possible have more waveclient packages if appropriate. > > Hmm... Separating the document model? What do you have in mind? > I am aiming more toward a high-level API (eventually), where most of > the work is done on the document model level (with lower level APIs > available if and when they are needed). So separating the document > model quite frankly hasn't occurred to me.. Unless I'm > misunderstanding what you mean. > > As for the UI, I'm not sure if there should be any UI code in the base > client. There could be so many different types and designs of clients, > that I can't really think of a good common ground UI-wise. There might > eventually even be clients that don't have any UI at all (*cough* > robots *cough*). > > Although now that I think about it, I guess there could be more layers > than I was planning. For example: > 1. The base client - just the most basic stuff like connection > management etc (this is what I was thinking of wrt the client's front > end base class). > 2. "Panel client" - common logic layer for panel-based clients like > the console client and the google wave web client. > 3. UI layer - provides the rendering and input capabilities. So you > could have one implementation that renders the client to the console, > and another that runs the same client logic in Swing, and a third that > uses something else (maybe GWT?). > 4. Maybe some other layer(s) between 1 & 2. > > Actually (this is coming to me as I write this), this can be taken a > bit further to an MVC pattern. The document model is the model, the > client's logic layer is the controller, and the rendering layer is the > view. Or maybe the rendering layer sits on top of the view and acts as > a service... > > Hmm... This is interesting. > > > > > 4. Clean up dependencies and adjust the build configuration to > > > generate a separate library. > > > > Sounds great. This was meant to be the fedone-api.jar build target but > > there are a few waveserver dependencies (C/S protocol for a start -- > would > > be nice to move this to a separate package), it got complicated, so we > just > > ended up dumping everything without a main method in there. That said, > it's > > broken. It would be great if this was cleaned up. > > I was thinking of basically taking fedone-api and separating it into > three chunks: > 1. fedone-api-server - everything server-specific; > 2. fedone-api-client - everthing client-specific; > 3. fedone-api-common - everything else (document model, OT, etc). > But I guess it may need to be split up into more pieces.. I haven't > really looked at it too deeply yet. > > > > > I will begin working on this within the next few days. I will post > > > further updates in this thread. > > > > One other thing -- I've upload a patch I will submit soon (i.e. between a > > week and a month :-) for review, though I will split it up a bit more > (it's > > huge) before requesting a review. > http://codereview.waveprotocol.org/25002/show, something to perhaps keep > in > > mind. > > I took a look. It looks good. > I was going to ask if you could give some extra priority to the bits > that affect the client, but that's roughly 2/3 of the patch. :-) > > There are definitely going to be some conflicts between our changes. > How do you suggest I should handle this? > > -- > > 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > > -- Brett Morgan http://domesticmouse.livejournal.com/ -- 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.
