Re: [Netrik-general] Re: Roadmap
Status: Beta
Brought to you by:
antrik
From: antrik <ola...@we...> - 2001-11-23 00:14:39
|
Hi, > > (Especially config file handling needn't be very sophisticated, as > > it is only a temporary solution anyhow...) > > Are you planning any secret feature which makes config files obsolete? > ;-) Well, yes. :-) I don't think we need to bother about it already now. But as you asked, It's probably better to tell the truth ;-) As explained on the netrik developement page, there are many things normaly done by proxies, that could be done better when directly supported by the browser, e.g. filtering (junkbuster) or caching/offline browsing (squid/wwwoffle). However, integrating them directly would cause several problems, the most important being: bloating the program; user permissions; but especially the fact that in such a constellation, the functionality could be used *only* by netrik itself. After considering this problem for a while, I came to the conclusion that there is only one solution: The system needs to be split up into a netrik proxy (trixy), that is *not* dependent on netrik, and the main program (netrik), that depends on the proxy. Now having such a "dedicated" proxy, it's probably a good idea to let it do as much as possible of the networking stuff, and keep it out of netrik itself as far as possible. (Now you will also understand why I don't bother too much about sophisticated HTTP handling...) And, as netrik has to tell the proxy about filtering and caching configuration anyhow, and as the proxy needs to have a URL-based configuration, and as it should speed up startup, and as it necessary to configure the proxy without using netrik, but not the other way round (as netrik is dependent on trixy anyhow), I decided that it's probably best to let the proxy also do the *whole* configuration handling... > I'm currently implementing a command line handling in the netrik code. That's nice :-) > I don't think that an option "debug" makes any sense, because this > debug code should certainly stay out of any final binary. Well, I think it *does* make sense; I even consider this quite important. Of course, we do not need it in a normal build (thus of course we will keep the compile time option); however, *if* compiled with -DDEBUG, it's really useful to have run time options controlling the actual behaviour. Actually, I think we should implement *several* options, to get a fine-grained control at run time... I need a version without debug output quite often myself. With the current solution, I always need to change the Makefile and recompile the whole program. Run time options would make things much easier... (In fact, this is one of the main reasons why I consider the option handling important :-) ) There are also other options that may require compile time *and* run time options; SGML parsing is probably one of them. > But I'm trying to implement the other options in the makefile You shouldn't bother about the actual options too much -- as soon as the handling is in, it shouldn't take me more than a few minutes to implement options at my will... > and will put the result into CVS as soon as I have a nice version. Don't wait until you have a *nice* version; just put it into CVS as soon as you have a *working* (even incomplete) version. After all, that's the whole idea behind CVS... > But don't expect too much as this is my first code using > getopt_long(). It doesn't look too difficult but you never know... Don't expect me to be too critical as I didn't ever use it either ;-) -Olaf- PS. Sorry for my answer being late. I had a problem with the mails :-( -- Don't buy away your freedom -- GNU/Linux |