> 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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
