- Dillo-dev - lists.mailman3.com

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

dpi send cmd error msg (Re: [Dillo-dev] Re: even more cookies SECURITY)

by corvid＠lavabit.com

Jorge wrote: > On Sun, Jan 24, 2010 at 11:04:52AM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > > > > > Do we currently have anything that needs to be > > > > > > fixed/implemented before a release would be sensible? > > > > > > > > > > Not that I remember. The only problem I recall was the error > > > > > message you reported with cookies and later seemed to be working > > > > > somehow. > > > > > > > > a_Dpi_send_blocking_cmd() gets upset when > > > > Dpi_blocking_read() doesn't get anything. > > > > > > > > So in the cookie dpi's srv_parse_tok(), > > > > after the Cookies_set(), I tried putting a > > > > a_Dpip_dsh_write_str(sh, 1, "text"), and > > > > that makes the error msgs go away for me. > > > > > > Sorry for the long time to answer. Here's near 35 Celsius among > > > other things... :-P > > > > > > You're right, there's one end expecting an answer that never > > > comes. Something like the attached patch should be enough. > > > > > > Note that this bug may cause some networking delays depending > > > on how the underlaying OS handles closing the socket when there's > > > a blocking reader (it may try to delay the close). > > > > > > The patch avoids this. > > > > I'm a bit hesitant to return a msg if we don't plan to do anything with it, > > but then if we have to send back something, it does make sense to put some > > information in there... > > That's the canonical way of doing it in DPIP. If the message > sender is not interested in the answer, he can ignore it (as in > this case). This allows for a simpler communication algorithm and > a uniform way of dealing with DPIP messages. > > The patch sends an answer that says whether the cookie was set. > It is easy to extend it to say what happened if the need arises. Committed.

Jan. 24, 2010