Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> >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?
Because it takes so much longer. Really, 40 lines of C -- most of
which aren't significant (blank lines, brace marks, trivial wrappers,
etc)... is that worth it, really? It would be fine to use marshal.c
from mod_webkit otherwise.
mod_webkit is configurable through Apache, I can't use that in
CAdapter.
Well factored is beautiful, but so is small, and they don't always go
together. More so with C. I mean, I wouldn't fight a library -- I
just don't see the point. mod_webkit is pretty small, CAdapter is
pretty small... I really doubt it would be possible to make a good
library so that the number of lines total in the library, mod_webkit,
and CAdapter are less then they would be without the library. And
what have you created? Maybe the worst of all -- an *interface* you
have to maintain.
> >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.
Something like restarting the AppServer requires more than can be done
in a library anyway. Personally, I think there should be a command to
restart the AppServer and leave it at that -- a .CMD or sh file can
handle the actual restarting, since the process may be locally defined
anyway. You don't need a library to use system().
> >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.
It's fine to retry, or whatever... I just don't see how that really
helps many real situations. Restarting implies retrying, and if I'm
going to put it in I just think I might as well make it more useful
than just dealing with the case of a manual restart. This is just my
delay tactic, not a plan for complete non-implementation.
> >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
mod_webkit doesn't do this currently.
> - read a config file
mod_webkit uses Apache's functions.
> - retry loop?
You can't really abstract this into a library, at least in C, and it
would be confusing even if you did.
> - restart app
I think this should just be a call to system() anyway, though I
suppose you could wrap that in a function for later change. But I
don't think that's necessary -- you only need one level of
abstraction.
> - future features X, Y and Z
They don't exist yet, so they won't help to fill the library out.
Ian
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
