On Monday, November 10, 2003, at 02:06 PM, Greg Stein wrote:
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.
C can do that?
:D
(I'm just kidding... I spent years doing digital audio stuff in C...)
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.
True. Any jakarta http-client developers hanging around to comment?
...
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.
Probably keeps it from being boring :)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr 203-247-1713(m)
[EMAIL PROTECTED]
