On Mon, Nov 10, 2003 at 01:43:52PM -0500, Geir Magnusson Jr. wrote: > On Monday, November 10, 2003, at 01:29 PM, Justin Erenkrantz wrote: >... > > I think there would/should be some collaboration between, say, a > > C-based HTTP client and a Java-based HTTP client. > > > > The problem they are attempting to solve is the same. They can pool > > their resources and come up with common strategies to dealing with > > 'real world' issues. How should you handle chunking errors? The > > design patterns in the code may or may not be similar though. But, > > what if they collaborated and came up with a similar API? Wouldn't > > that be exceptionally powerful? I think so. > > In theory yes, but in practice? And w/o clubbing the API flat by > removing useful OO-ish mechanisms such as interfaces and such, how > could you do a C and Java API? I guess you could define things in > terms of structs and getter/setter-less classes, but to what end?
Well, I think sharing a model would be quite possible. Connection objects, how to inject requests into a connection, how to deal with arrival of responses, how to deal with synchronization issues in a multiplexed connection model, etc. But yah, Justin might have stretched a bit with "API", but I do think a lot of similarity is possible in terms of a conceptual model. The real part is his first item: what kinds of errors are seen in a real-world operating environment? What needs to be worked around? I know that some old Apache servers didn't do Digest properly, and that IIS might *still* not do it right. Is that something to watch out for? What about the Expect header? How should that be handled since some servers don't deal with it? There is a lot of information about the environment that can be shared between HTTP client developers. >... > > And, I think *most* 'non-Java' people can grok Java (at least read > > it). I just wouldn't choose to write anything in Java unless I was > > forced to. But, that's my own personal bias and says a lot about the > > types of applications I usually write. -- justin > > The personal bias I understand and support (although I can't personally > imagine going back to C myself unless I was writing a device driver or > something), but what aspect of the apps prevent you using C++ ? C++ still isn't as portable as vanilla C. Justin (and myself, fwiw) tend to want to write very portable applications [based on APR]. That naturally means using plain old C. That isn't to say we aren't using OO concepts such as encapsulation, vtables, and such. It just gets done explicitly, rather than via language constructs. Cheers, -g -- Greg Stein, http://www.lyra.org/
