Fwd: Re: [Dillo-dev]Plugin infrastructure
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 -------------------------------------------------------
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.-
participants (2)
-
Garrett Kajmowicz -
Jorge Arellano Cid