January 2010 - Dillo-dev - lists.mailman3.com

dpidc

by jcid＠dillo.org

On Tue, Jan 26, 2010 at 06:08:03PM +0000, corvid wrote: > Rogut??s wrote: > > [...] > > P.S. Is everyone comfortable with the colors at dillo.org? The logo is > > nice, but the light background with white text means sore eyes to me. > > I also find it hard to read. > It might even be worth making it plain by default, and having a little > stylesheet to add color. There's a volunteer web site designer working on a new scheme. Let's hope people like it. I'll let you know when he sends me a draft. -- Cheers Jorge.-

Jan. 26, 2010

dpidc

by corvid＠lavabit.com

Rogut?s wrote: > Johannes Hofmann (2010-01-26 13:55): > > On Tue, Jan 26, 2010 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > > > On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > > > > Wouldn't that be unusual for it to be in anyone's path? > > > > > > > > > > The idea was to have most dillo-related things in that > > > > > directory. Subdirectories in ~/bin look rare, so lacking a better > > > > > idea it ended in ~/.dillo > > > > > > > > To me, it makes the most sense to put it wherever dillo goes. > > > > > > Yes, I agree. > > > Sorry, I was thinking of the dpis. > > > > > > The user may not have permission to install system-wide, and in > > > that case probably dillo, dpid, and dpidc should be in ~/bin and > > > the dpis in ~/.dillo/dpi. > > > > Do we really need to add special handling for this? > > Normally I would expect binaries in $PREFIX/bin and dpis also in > > $PREFIX/bin or $PREFIX/libexec. > > The user has to use a PREFIX where he has write access of course. > > But then the rest is taken care of by autoconf and friends, no? > > At most, the instructions to build dillo [1] could include suggestions how > to run dillo locally. No more special handling should be needed (autoconf > takes care of this case, yes). > > The instructions could be as scarce as this (hope they are correct): > If you choose to install under a different prefix > (./configure --prefix=dir), note that dillo needs > the binaries dpid, dpidc to be in your $PATH. Yes, judging from what I can find on web forums, it is common for people to try dillo and not be able to get the dpi stuff to work. And, since they don't want to battle with something when they don't even know whether they like it yet, they give up. Spelling out what is happening (on the website and in README) would be a very good thing, I think. (Plus I personally like to put the pieces of programs under my user's dir manually rather than letting make install do whatever it wants.) I think the requirements are: - dillo and dpidc need to be in the path somewhere. - dpid can be in ~/.dillo/, or in bindir, or in the path - the dpi structure (dpi/[dpi]/... goes under ~/.dillo or libdir/dillo. - dpidrc goes in ~/.dillo or sysconfdir/dillo (And a bit about how dillo finds dpid, and then dpid finds the dpis based on dpidrc and all that...) > P.S. Is everyone comfortable with the colors at dillo.org? The logo is > nice, but the light background with white text means sore eyes to me. I also find it hard to read. It might even be worth making it plain by default, and having a little stylesheet to add color.

Jan. 26, 2010

dpidc

by rogutes＠googlemail.com

Johannes Hofmann (2010-01-26 13:55): > On Tue, Jan 26, 2010 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > > On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > > > Wouldn't that be unusual for it to be in anyone's path? > > > > > > > > The idea was to have most dillo-related things in that > > > > directory. Subdirectories in ~/bin look rare, so lacking a better > > > > idea it ended in ~/.dillo > > > > > > To me, it makes the most sense to put it wherever dillo goes. > > > > Yes, I agree. > > Sorry, I was thinking of the dpis. > > > > The user may not have permission to install system-wide, and in > > that case probably dillo, dpid, and dpidc should be in ~/bin and > > the dpis in ~/.dillo/dpi. > > Do we really need to add special handling for this? > Normally I would expect binaries in $PREFIX/bin and dpis also in > $PREFIX/bin or $PREFIX/libexec. > The user has to use a PREFIX where he has write access of course. > But then the rest is taken care of by autoconf and friends, no? At most, the instructions to build dillo [1] could include suggestions how to run dillo locally. No more special handling should be needed (autoconf takes care of this case, yes). The instructions could be as scarce as this (hope they are correct): If you choose to install under a different prefix (./configure --prefix=dir), note that dillo needs the binaries dpid, dpidc to be in your $PATH. [1] http://www.dillo.org/source.html P.S. Is everyone comfortable with the colors at dillo.org? The logo is nice, but the light background with white text means sore eyes to me. -- -- Rogut?s Sparnuotos

Jan. 26, 2010

dpidc

by Johannes.Hofmann＠gmx.de

On Tue, Jan 26, 2010 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > > Jorge wrote: > > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > > Wouldn't that be unusual for it to be in anyone's path? > > > > > > The idea was to have most dillo-related things in that > > > directory. Subdirectories in ~/bin look rare, so lacking a better > > > idea it ended in ~/.dillo > > > > To me, it makes the most sense to put it wherever dillo goes. > > Yes, I agree. > Sorry, I was thinking of the dpis. > > The user may not have permission to install system-wide, and in > that case probably dillo, dpid, and dpidc should be in ~/bin and > the dpis in ~/.dillo/dpi. Do we really need to add special handling for this? Normally I would expect binaries in $PREFIX/bin and dpis also in $PREFIX/bin or $PREFIX/libexec. The user has to use a PREFIX where he has write access of course. But then the rest is taken care of by autoconf and friends, no?

Jan. 26, 2010

dpidc

by jcid＠dillo.org

On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > Jorge wrote: > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > Wouldn't that be unusual for it to be in anyone's path? > > > > The idea was to have most dillo-related things in that > > directory. Subdirectories in ~/bin look rare, so lacking a better > > idea it ended in ~/.dillo > > To me, it makes the most sense to put it wherever dillo goes. Yes, I agree. Sorry, I was thinking of the dpis. The user may not have permission to install system-wide, and in that case probably dillo, dpid, and dpidc should be in ~/bin and the dpis in ~/.dillo/dpi. -- Cheers Jorge.-

Jan. 26, 2010

dpidc

by corvid＠lavabit.com

Jorge wrote: > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > Wouldn't that be unusual for it to be in anyone's path? > > The idea was to have most dillo-related things in that > directory. Subdirectories in ~/bin look rare, so lacking a better > idea it ended in ~/.dillo To me, it makes the most sense to put it wherever dillo goes.

Jan. 26, 2010

dpidc

by jcid＠dillo.org

On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > Wouldn't that be unusual for it to be in anyone's path? The idea was to have most dillo-related things in that directory. Subdirectories in ~/bin look rare, so lacking a better idea it ended in ~/.dillo > - Do you think it would be silly to make a little manpage for dpidc? Yes. AFAIS the main use of dpidc is "dpidc stop". The "chat" idea is interesting for testing dpis. I don't remember having implemented it though! :). Once it works in a useful way, a man page may help. > - I'm contemplating making dpidc's exit values distinguish between > the cases of: > 1) Bad usage. Wrong number of args. > 2) I can't find the stuff to communicate with dpid (either because this > the first use of dillo, or the dpi system has been changed). > 3) Connection refused. I think dpid just isn't running right now. > 4) Something is breaking while communicating with dpid. Accurate error messages are certainly welcomed. -- Cheers Jorge.-

Jan. 25, 2010

connection limit (was: display: inline)

by Johannes.Hofmann＠gmx.de

On Mon, Jan 25, 2010 at 06:50:44PM +0900, furaisanjin wrote: > 2010/1/22 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > Connections to proxies are also limited - with the same limit as for > > normal hosts (4 atm). > > > > Please give it a try. If it works out ok we might even consider it > > for the release. > > I'm using the new patch for a few days and it seems that I don't see > the problem. Actually I changed proxy connection limit to 10 and this > may also help with patched Dillo. Good. It's in the main repo now with a configurable connection limit (http_max_conns in dillorc). Regards, Johannes

Jan. 25, 2010

connection limit (was: display: inline)

by furaisanjin＠gmail.com

2010/1/22 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Connections to proxies are also limited - with the same limit as for > normal hosts (4 atm). > > Please give it a try. If it works out ok we might even consider it > for the release. I'm using the new patch for a few days and it seems that I don't see the problem. Actually I changed proxy connection limit to 10 and this may also help with patched Dillo. Regards, furaisanjin

Jan. 25, 2010

dpidc

by corvid＠lavabit.com

- Why does install-dpi-local put dpidc in ~/.dillo, anyway? Wouldn't that be unusual for it to be in anyone's path? - Do you think it would be silly to make a little manpage for dpidc? - I'm contemplating making dpidc's exit values distinguish between the cases of: 1) Bad usage. Wrong number of args. 2) I can't find the stuff to communicate with dpid (either because this the first use of dillo, or the dpi system has been changed). 3) Connection refused. I think dpid just isn't running right now. 4) Something is breaking while communicating with dpid.

Jan. 25, 2010