You want to rewrite the OT lib in perl? Or do it in C and link it in? =) On Tue, Dec 8, 2009 at 6:58 AM, [email protected] <[email protected]>wrote:
> Although I agree we should keep a GWT compiled version in mind, I > would suspect that this effort should prioritize making the best > server and api's. Many custom clients should be able to communicate > with it. > > Personally I want a perl client. But I'm crazy that way. > > -Brian > > On Dec 5, 8:38 am, Michael K <[email protected]> wrote: > > > The thing to be careful about is how many classes you expect to load > into a > > > browser based gwt app. Unless your target audience is running bleeding > edge > > > chrome, having a lot of classes is going to lead to sluggish user > > > experiences through gc abuse. > > > > This is an interesting point. I must admit I'm not very familiar with > > GWT yet (though I'd like to change that). I'll keep this in mind. > > > > I don't think there would be a hell of a lot of classes, and they > > probably won't be very complex classes. But there could be a lot of > > instances if you have a large wave open. I suppose that an object pool > > might help here, but there would still be a large memory footprint in > > that case, which could still slow things down.. > > > > On the other hand, since GWT is being used for the Google Wave web > > client, I'd expect it to be optimized quite heavily (if not yet, then > > eventually), including the memory management. > > > > > Are you taking the wave robot api as a touch point for your api design > > > ruminations? > > > > I did consider it, yes. But the robot api is very heavily based on > > events, which I'm not sure is the best option here. For one, the > > primary input of a robot are changes to the wave made by other > > participants. But the primary input for a client are (usually) the > > actions of the user. Further, there is no robot api implementation on > > FedOne (although there is a basic agent API, which is somewhat > > similar), so this may require a lot of extra work. And it could > > actually lead to more classes (if not more objects) since you would > > need both the document model and the event model. > > > > I do agree that the event model as used in the robots api could be > > useful for a client. And it would certainly be interesting to be able > > to run robot code on top of a client backend. Actually, the client > > already uses a listener interface for wavelet operations, so this > > could be extended.. > > > > I'll have to give it another look when I get to that point. > > -- > > 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.
