- Dillo-dev - lists.mailman3.com

[Johannes.Hofmann@gmx.de: Re: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

[jcid@dillo.org: Re: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

[Johannes.Hofmann@gmx.de: Re: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

[jcid@dillo.org: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

Jorge wrote: > I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, > that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. I think it was gentoo that was having an inbuf_t detection problem.

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

On Thu, Nov 20, 2008 at 09:14:56AM -0300, Jorge Arellano Cid wrote: > On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote: > > > > Is this a good way to do it or is there a smarter way? All > > comments and advice are welcome. > > It looks OK. Good! > I wonder why a dpi is deemed necessary for this. I don't know whether it is necessary. That's why I asked for comments. I just thought that HTTP authentication looked rather "cookie-ish" and decided to copy and modify the cookies implementation. I'm new to this part of Dillo so I am following established practice. I already have a dummy auth dpi running and hooked into the main Dillo program, so I think that the dpi part of things is by far the easiest bit. The most work is actually implementing authentication! > Isn't an implementation of a_Dialog_user_passwd() enough to solve > it? It certainly appears to be the missing link, in the sense that everything else that authentication needs is the kind of thing that the cookies dpi already does and therefore counts as a solved problem already. I plan to continue with the dpi-based implementation on the grounds that the biggest part of the task is implementing authentication and a_Dialog_user_passwd(), and that code will not depend on whether we do authentication in the dillo main program or a dpi. If we decide to move authentication out of the dpi and into dillo itself then I will just move the authentication code around and delete some dpi wrapper code, which won't be much work. At least that's how I expect it will work. Stay tuned, and please comment further. Jeremy Henty

Nov. 20, 2008

a list of what dillo2 runs on

by ljmoore＠wightman.ca

On Thu, Nov 20, 2008 at 09:12:35AM -0300, Jorge Arellano Cid wrote: > On Wed, Nov 19, 2008 at 08:01:49PM -0500, Larry Moore wrote: > > My system isn't representative of any mainstream (debian on a m68k ) but > > will download from cvs, compile and soforth when prompted. > > What system do you have? > > I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, > that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. > > -- > Cheers > Jorge.- It's a Macintosh Quadra 610 which has been running debian since the woody release At the moment, the unofficial etch-m68k with some lenny packages. As I said, rather non-standard. -- "I don't think I've found God, but I may have seen where gods come from." Terry Pratchett

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by jcid＠dillo.org

On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote: > > I'm implementing an HTTP AUTH dpi (based on the cookies dpi) and I'd > appreciate comments on how I'm doing it. > > (Motivation: (a) I'm tired of the irony of having to use Firefox to > log on to the FLTK Trac Wiki to update the Dillo page, (b) this will > be a useful primer for hacking on the https dpi.) > > The problem is that the dpi must prompt the user for a username and > password but src/dialog.cc only supports dialogs that present a choice > of buttons. > > I think I'll have to add a_Dialog_user_passwd() to src/dialog.cc to > create a modal dialog, return the clicked button and write the > contents of the dialog entries into a struct. Then I can add a > wrapper for it to src/dpiapi.c and hook it into a_Capi_ccc(). That > will let the dpi query the user. > > Is this a good way to do it or is there a smarter way? All comments > and advice are welcome. It looks OK. I wonder why a dpi is deemed necessary for this. Isn't an implementation of a_Dialog_user_passwd() enough to solve it? -- Cheers Jorge.-

Nov. 20, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Wed, Nov 19, 2008 at 08:01:49PM -0500, Larry Moore wrote: > On Tue, Aug 26, 2008 at 05:52:43PM +0000, corvid wrote: > > Christopher Illies wrote: > > > On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > > > > I wonder whether we could get someone for each system who > > > > would have the responsibility (or, let's say "_glory_" :) > > > > of responding to "Hey, we changed [some configuration stuff] > > > > in the latest CVS. Does it work fine on your system?" messages. > > > > > > I can take that part for FreeBSD for now and will respond when such > > > messages are posted to this list. Also, I can do a fresh compile every > > > two weeks or so. > > > > Cool! > > > > > My system isn't representative of any mainstream (debian on a m68k ) but > will download from cvs, compile and soforth when prompted. What system do you have? I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. -- Cheers Jorge.-

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

I'm implementing an HTTP AUTH dpi (based on the cookies dpi) and I'd appreciate comments on how I'm doing it. (Motivation: (a) I'm tired of the irony of having to use Firefox to log on to the FLTK Trac Wiki to update the Dillo page, (b) this will be a useful primer for hacking on the https dpi.) The problem is that the dpi must prompt the user for a username and password but src/dialog.cc only supports dialogs that present a choice of buttons. I think I'll have to add a_Dialog_user_passwd() to src/dialog.cc to create a modal dialog, return the clicked button and write the contents of the dialog entries into a struct. Then I can add a wrapper for it to src/dpiapi.c and hook it into a_Capi_ccc(). That will let the dpi query the user. Is this a good way to do it or is there a smarter way? All comments and advice are welcome. Regards, Jeremy Henty

Nov. 20, 2008