- Dillo-dev - lists.mailman3.com

Re: Fwd: Re: [Dillo-dev]Plugin infrastructure

by Jorge Arellano Cid

On Mon, 12 Jul 2004, Garrett Kajmowicz wrote: >> 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. Yes Nicolas, the html interface is an important part of the dpip feature set. Now, each dpi is different and that's why flexibility is important. I mean, for bookmarks and preferences (and probably for general purpose applications like the dillo-based control center of DSL linux), HTML is perfect. For the downloads, a native GUI inside the dpi, is an easier approach, and in the https case, dialog windows through Dillo by means of a dpip request seem to be the most adequate. > > 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 :-) It's important to notice that coding the https dpi as a server (instead of a filter) has some advantages. BTW, this is what we have in mind with Madis. A server https dpi can more easily manage session caching and certificate management (remembering, saving, loading, ...). A single instance that forks or launches threads to do the work while keeping a common central management. BTW, we agree that implementing and testing with a filter dpi before turning it into a server dpi is a good approach. > > 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. In this case we'll try the dialog window with dpip... I foresee this tasks (by my side): 1.- Merge the https into the CVS so you can sync from there. 2.- implement a dpip command to provide for a simple dialog. (so handle_certificate_problem() can be filled in). 3.- Polish the common API for developing dpis and adjust the dpi set to the new functions. 4.- Implement a dpip_build_command() function into the lib and make the dpi set use it. 5.- Merge my new patches for bookmarks, downloads, and interface inside dillo. 6.- Review the file dpi. I hope to have this done and uploaded by Friday (1 to 5). Now, only 1.- and 2.- constitute a bottle neck for https, so I'll try to push them first (hopefully by Wednesday). The idea is to remove the bottleneck so you can keep on working and testing the https dpi. Cheers Jorge.-

July 13, 2004

[Dillo-dev]0.8.2 - No PNG support, but config cound PNG available (attachment)

by Geek

Hi, I just compiled and installed 0.8.2 on my Debian stable and gave it a shakedown. It doesn't display PNG images. 0.8.1 and earlier, no problems. I have attached the config.log file Thanks for any assistance. -- Gregg t3h g33k http://geek.scorpiorising.ca

July 13, 2004

RE: [Dillo-dev]Plugin infrastructure

by Eric Gaudet

Dillo's html rendering capabilities are what we should use for advanced forms. We don't want to duplicate the form widgets into a native-gtk version like mozilla does with xul. The pageflow, the forms, images etc ought to be in html, even if it's a dpi serving them. Having a login/password modal box seems to be what people are used to, so I can see why we'd like to have that. I can imagine dpis other than https needing a login/password box, but I'm not sure I can imagine that for non-login purposes. In any case, anything more complicated than one string, one or two text boxes with lables (possibly hidden for passwords) and 1 or 2 buttons certainly belongs to a dedicated html page the dpi would build. I could live with an intermediate html login page for https or any other dpi myself. Best, EG > -----Original Message----- > From: dillo-dev-admin(a)auriga.wearlab.de > [mailto:dillo-dev-admin@auriga.wearlab.de] On Behalf Of > Garrett Kajmowicz > Sent: Monday, July 12, 2004 3:26 PM > To: dillo-dev(a)auriga.wearlab.de > Subject: Re: [Dillo-dev]Plugin infrastructure > > > 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 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-> bin/mailman/listinfo/dillo-dev > >

July 12, 2004

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