July 2004 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]Plugin infrastructure

by Nicolas Pouillon

[Mon, 12 Jul 2004 09:33:55 -0400] Garrett Kajmowicz <gkajmowi(a)tbaytel.net> eut le bonheur d'écrire: > Something with the DPI instrastructure needs to be considered - what > to do if a plugin needs to prompt the user for some information. [...] In the discussions before introduction of dpi was the point UI could entierely be done using standart html, rendered by dillo itself. Maybe we could use this here. I would see two (new) dpi commands: -Pop a new dillo window (maybe with some args: modal, no toolbar, no addressbar..., set its size, url) -Make a window reload So dpi could make a window pop for asking anything about certificates, with a standart html form in it. It would allow to change window title (through <title>) and make the gui customisable for future needs, and even be portable for gtk->other toolkit change. I thought of the 'reload window' feature not directly for https, but for download dpi. This would allow us to update the status of current downloads; shown in a dedicated window, somewhat ala Firefox, but again, entierely in html. -- Nipo

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

I just came up with two other dialog box types we might need: A window with alterable caption/message text and either one or two text boxes with associated labels. One or both of the boxes should be able to be set in "password" mode. I'm not sure if that counts as one or two, so I'm inflating my estimates to look more impressive :-) - Garrett Kajmowicz

July 12, 2004

Fwd: Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

> In the discussions before introduction of dpi was the point UI could > entierely be done using standart html, rendered by dillo itself. > > Maybe we could use this here. > > I would see two (new) dpi commands: > -Pop a new dillo window (maybe with some args: modal, no toolbar, no > addressbar..., set its size, url) > -Make a window reload > > So dpi could make a window pop for asking anything about certificates, > with a standart html form in it. It would allow to change window title > (through <title>) and make the gui customisable for future needs, and > even be portable for gtk->other toolkit change. > > I thought of the 'reload window' feature not directly for https, but for > download dpi. This would allow us to update the status of current > downloads; shown in a dedicated window, somewhat ala Firefox, but again, > entierely in html. That is very interesting, but causes two problems. First of all, from what I have seen , it looks like it would be difficult to implement modal dialog boxes. This is important for security warnings so that they are not hidden or confused with other Dillo warnings. Secondly, this approach causes some problems. I am approaching this from the perspective of the https filter dpi, but I assume that the same problem would apply to any other related dpi. Firstly, a filter dpi runs in its own process for each call, not as a server. Thus every time a call is made to the https filter dpi, it runs in its entirety. This makes it difficult to handle a response from the user because the dpi is then required to write a web server capable of at the very least parsing http GET requests, which means opening up a socket and so forth. Needless to say, handling that is somewhat of a challenge from a filter dpi perspective. Secondly, for the https application, cookie/post/get datais likely to be sent, which means that any rerequest would have to be able to pass that data on exactly. Third, the https verification needs to be done after the ssl session is estabilshed, but before the http request is made (for security reasons). Thus any complicated scheme could result in multiple connections being made. Fourthly, I don't like it. That's the most important one of all :-) The html prompt window isn't a bad idea, but causes a lot of coding headaches on the dpi other end. But that's just my thought. If you think that an html prompt window would work, I'd appreciate a modified "hello" filter dpi as an example from which I could implement the required code. Thanks for the feedback - Garrett Kajmowicz -------------------------------------------------------

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

> In the https case, it seems we only need (by now) a yes/no > answer for a certificate that can't be verified. > > Please send me the list for all the question/generic dialogs > you foresee. > If we are going to allow dialogs we need to have something generic enough that developers will not feel straightjacketed, which concrete enough that it isn't a nightmare to implement. Ideally it will not be tied to the underlying widget library so that we can switch widget libraries(if need be) without having to rewrite plugins in the future. There are a few dialog types that I see as being useful. The first is the file save-as dialog. This might simplify some of the FTP code (I haven't looked at the core app side of things). Next, a generic dialog which supports a custom message, as well as customizable text on up to three buttons. Custom caption for the window is nice. I think we can assume that it's a modal dialog box. This will allow the programmer to deal with almost any situation needed. In the https example, consider the options of: trusting indefinitely, trusting for this connection only, or refusing the connection. That requires three buttons. The indefinite trust is required to deal with self-signed sites that we don't want to have to click "yes" to for every file. These are the two which come to mind immediately. I would avoid limiting the possabilities so that when we come up with something we had not anticipated we will not run into any problems. > The question dialog through dpip for continuing or aborting > over non-verifiable certificates, is the bottle-neck now. I'll > start coding it ASAP. Thanks. Please let me know what you are doing so that I can follow everything. This will make it easier for me to contribute. You noted that you had made some changes to what I sent you. Have you commited the changed to CVS? If so, I'll blow away my current tarball tree and pull everything down from CVS. If not, please let me know where you are going so I can adjust my development accordingly. Thanks. - Garrett Kajmowicz

July 12, 2004

[Dillo-dev]sparc success for 0.8.2

by Riccardo Mottola

Hey, I just wanted to report that the final release of dillo compiles and seems to work fine here on solaris 6 -Riccardo

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Jorge Arellano Cid

Hi Garret, I just finished reading the whole tarball you sent me. It's very interesting. I'm planning to make some modifications on it to provide a generic new API for sending data (I also have a new dpi for file:/, some fixes for buffering in the transfer for bookmarks, some changes to downloads, also to consider cookies and preferences). BTW, with bookmarks I had already changed the data sending routines to provide for streams and flushing. Something like: <q> int send_data_chunk(int OutFD, char *Data, size_t DataSize, int flush); int send_data_string(int OutFD, char *str, int flush); </q> that provides for better tunning from each dpi (e.g. the new bookmarks transfers also run quickly on the 2.6.x series of the linux kernel). The idea of grouping common functions into something like a dpi library was present from a long time ago. This is a good opportunity to start with it. :) I have to think a bit more about the API for data sending. The plan is to have it merged on CVS before Friday. On Mon, 12 Jul 2004, Garrett Kajmowicz wrote: > Something with the DPI instrastructure needs to be considered - what to do if > a plugin needs to prompt the user for some information. Yes, this was considered. ...and it is much like what you describe. > > The need for this first came about while developping the https plugin - there > needs to be a way to prompt the user in the event that the foreign system > isn't trusted. > > This can currently be done through the use of direct calls to Gtk (I assume), > but this is not the best result. It requires that everybody who needs to do > user prompting write their own dialogs. It creates additional dependancies > for the dpis. And it makes code upgrades more difficult - Should Dillo > switch to another toolkit in the future for whatever reason (perhaps Gtk2?), > all of the DPIs need to be rewritten. And in the event of multiple instances > of Dillo running, it becomes impossible to determine which instance the > prompt is for. Yes, those are the two possibilities: a) Dialogs through Dillo (using dpip). b) Native dialogs. Currently b) seems inadequate, but for graphical dpis, it's different (for instance the graphical downloads: it's simpler to add "cancel" buttons in the native window). In the case of https, a) looks better. > > My proposed solution to this problem is to create a new dpi command which is > used to prompt the user for what to do. It should allow (require/default?) > modal dialog boxes so that the prompt is associated with the Dillo instance > the plugin is using. > > I am suggesting that the dpi command be 'prompt_user'. There would be one > manditory field, 'type' which would indicate the type of prompt to use. > Example values might be 'dialog' or 'file_save'. These types would be > extensible. > > From there, additional tags would be allocated based on the type of prompt. > For example, a 'file_save' prompt might have a default_filename tag. A > 'dialog' would likely have a title, a message, and up to 3 button texts. > > In all cases, the responce should be a dpi message of type 'user_response' > with a 'response' tag holding the value of the user input. I'll have to search my archives. I'm sure I wrote something about this long ago... AFAIR, there was the "question dialog" with fixed alternatives, and things like that. In the https case, it seems we only need (by now) a yes/no answer for a certificate that can't be verified. Please send me the list for all the question/generic dialogs you foresee. > At least this is my proposal. I'd like some feedback on it, and especially > suggestions or better ideas. The question dialog through dpip for continuing or aborting over non-verifiable certificates, is the bottle-neck now. I'll start coding it ASAP. Of course it would be very helpful to know in advance the other possible dialogs. To design a good API, that is. Cheers Jorge.-

July 12, 2004

[Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

Something with the DPI instrastructure needs to be considered - what to do if a plugin needs to prompt the user for some information. The need for this first came about while developping the https plugin - there needs to be a way to prompt the user in the event that the foreign system isn't trusted. This can currently be done through the use of direct calls to Gtk (I assume), but this is not the best result. It requires that everybody who needs to do user prompting write their own dialogs. It creates additional dependancies for the dpis. And it makes code upgrades more difficult - Should Dillo switch to another toolkit in the future for whatever reason (perhaps Gtk2?), all of the DPIs need to be rewritten. And in the event of multiple instances of Dillo running, it becomes impossible to determine which instance the prompt is for. My proposed solution to this problem is to create a new dpi command which is used to prompt the user for what to do. It should allow (require/default?) modal dialog boxes so that the prompt is associated with the Dillo instance the plugin is using. I am suggesting that the dpi command be 'prompt_user'. There would be one manditory field, 'type' which would indicate the type of prompt to use. Example values might be 'dialog' or 'file_save'. These types would be extensible. From there, additional tags would be allocated based on the type of prompt. For example, a 'file_save' prompt might have a default_filename tag. A 'dialog' would likely have a title, a message, and up to 3 button texts. In all cases, the responce should be a dpi message of type 'user_response' with a 'response' tag holding the value of the user input. At least this is my proposal. I'd like some feedback on it, and especially suggestions or better ideas. - Garrett Kajmowicz

July 12, 2004

Re: [Dillo-dev]HTTPS

by Jorge Arellano Cid

On Sun, 11 Jul 2004, Garrett Kajmowicz wrote: > OK - I have created a preliminary HTTPS implementation using openssl. It > checks to see if a site certificate chain is valid. Unfortunately, I'm not > sure how to create a dialog to prompt the user, so the "ask the user" > function just returns continue. Should I use glib/gtk or some dpi > communication message? > > The totality of the dpi stuff I have done is about 15k or so. Please let me > know if you are interested Absolutely! I got so tired after managing everything to be on place for the last release, that decided to stay away from the computer for the weekend... Please excuse me, but receive our welcome anyway! > and I will email it to you post haste. Yes, it's very interesting and I surely want to give it a try. I'll resume my duties this monday. Cheers Jorge.-

July 12, 2004

[Dillo-dev]HTTPS

by Garrett Kajmowicz

OK - I have created a preliminary HTTPS implementation using openssl. It checks to see if a site certificate chain is valid. Unfortunately, I'm not sure how to create a dialog to prompt the user, so the "ask the user" function just returns continue. Should I use glib/gtk or some dpi communication message? The totality of the dpi stuff I have done is about 15k or so. Please let me know if you are interested and I will email it to you post haste. - Garrett Kajmowicz

July 11, 2004

[Dillo-dev]HTTPS

by Garrett Kajmowicz

Is anybody currently actively working on HTTPS support? If not, how much work would be involved? I have some basic experience working with OpenSSL. Unfortunately, I have almost no gtk experience (I'm a Qt kind of person). I have some spare time, and would be willing to help, if I could, though I've never worked on a web browser before. Closest I have come is writing PHP. - Garrett Kajmowicz

July 10, 2004