At 05:59 PM 5/29/2001 -0500, Ian Bicking wrote:
>Well, retry is just a code structure issue, not something that could
>fit in a library. It could be added easily enough.
Retrying has 2 settings: How many times to retry and how long to wait in
between. Code is required to read those settings.
>The whole thing is just 248 lines, there's not a lot there to share
>anyway. The most useful might be the marshalling. mod_webkit uses
>Python's marshalling functions, I think. I just recreated the small
>portion needed to send the request, with about 40 lines. The other
>portion might be reading and parsing address.text, and opening the
>connection to it. That's 25 lines of C. Not really worthy of reuse.
Disagree. Things like marshalling, reading address.text, reading the config
will continue to grow over time. Why write all this stuff twice?
>I could add the retry, but just haven't. I would actually prefer to
>add something that restarted the AppServer upon failure or timeout, as
>I feel this solves the problem much more robustly than retrying does.
So here's another example. If we write code to restart the app server, I
understand that we have to write it once in Python and once in C. But I
don't ever want to write it four times in Python (which is why we have a
base Adapter class) and twice in C.
I already have problems with the various AppServer classes which duplicate
code and make maintenance more of a chore.
>I don't think it should be too hard to maintain, really. All the
>adapters are well partitioned from the rest of Webware. As long as
>Webware continues to take input over the socket in the same format,
>the adapter won't need any updating.
It would be strange to have a mismatch in features:
- mod_webkit: will retry, but not restart
- c cgi: will not retry, but will restart
Our current situation is that switching adapters is a matter of
configuration preference, not functionality. I'd like to keep it that way.
>The one big problem is that it doesn't have any configurability,
>except to recompile it. Right now there's nothing to configure except
>the location of address.text, which is just as easily configured with
>a symbolic link. If there were timeouts and such, those would need
>configurability, though maybe recompiling would be fine too.
CAdapterLib
- read address.text
- read a config file
- retry loop?
- restart app
- future features X, Y and Z
-Chuck
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
