Search results for "plugin" - Dillo-dev

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

Hello, Sorry for the huge mail. :) >> # Moving the dns stuff to IO. >> # Move all the socket stuff into IO.c, the module that wants to handle >> opening the connection should also close it (all non-internet sockets, >> like files. Unix sockets may be added to IO.c.). > Gzilla had a flat design, we've come a long way to layer dillo > and to separate its code in modules. It's not what you think, what I meant was to move dns.c|h to the IO directory, not to move the code from those files into IO.c, I would never do that. What I want to do is to move the code into the modules where it belongs. I see no reason why the IO module shouldn't handle all the socket related stuff, currently http.c makes a new socket and connects it, then it passes it more or less to the IO module. It seems more logical and modular to me when the IO module does those TCP/IP specific things when http calls IO_new. Let the IO module do the IO, and the http module do the http related things, that's my opinion. I don't see the http module doing anything special with the dns info, so it probably makes more sense to let the IO module use the dns module too. You seperated the code in modules and layers, what I want to do now is to move code to the place it belongs, making Dillo in my opinion more modular, overall simpler and more flexible. Currently this has the effect that the IO modules becomes bigger and more complex, but it also means that the http module will be smaller and simpler, and that it's easier to add more http like modules in the future. What's bad about the current ccc functions? The problem is that currently not all modules can communicate blindly with other modules via ccc functions, because different ccc functions expect different parameters. Also most of the time modules know exactly with which module they talk, they have no choice, otherwise they don't know what parameters to give and expect. Now you use ccc functions like a sort of bad used void pointers: You know what you get, you know what you call, but still tunnel it through a typeless function. You mix a general API with module specific API's, making things only very confusing and unclear. All I want is a clear API. I see how ccc functions are usefull, and what their point is, but that is not my problem with them, the idea of a sort of linked list of functions is nice, but the implementation isn't very well if you ask me. Also the API used internally in Dillo isn't consistent. For example: Why call a_IO_new and not IO_ccc with OpStart? Things are unnecessary complicated and inflexible now. It's not easy to unravel the spaghetti, but it's doable, and when you're done you've a nice clean internal API that makes implementing library plugins a piece of cake. > It serves to isolate the query process from the answer process. > Also as dillo uses pipes to talk to itself, it makes sense to have read-only and write-only FDs. Of course it can be merged, but it may be not simple. With pipes it makes sense yes, but in general all other connections are bidirectional. Dillo uses mostly TCP, then it's one socket, one connection, one fd. And one IOData structure if you ask me. If you use one IOData structure that is also bidirectional, then all you need to do with pipes is to still use two IOData structures, but only for pipes. One IOData structure for each fd makes most sense to me. Connection caching. You say that Dillo has it, but when I open a website, and look with netstat, Dillo has no open connections. Same experience with debug output. Maybe Dillo has it with dpi connections, I don't know, didn't look at that code yet, but in general Dillo has no connection caching, at least not the kind I mean. The one I would want to have is that keeps connections open until the server closes them, or until they time out (I'm not sure if all connections should be cached, or only the one to the last domain/current site). > In the past that approach was used. ~/.dillo ended having a > splash file for each release. The point is that what's more memory consuming is the widget tree for rendering, not the source itself. I do not know (nor want to know ;) how you first implemented it, what I was thinking about is opening by default the about html file. To have something that does exactly the same as now, all you have to do is open by default e.g. /etc/dillo_splash.html. It takes about 5 lines, patch is written within 15 minutes, most work is getting rid of the old code. And instead of keeping that 10K splash info all the time in memory, you now don't use any memory at all for it, except the one to render it, but that's gone after going to another site (if we can tell the cache to not cache it anyway, but that's the same for the current implementation). Putting an about file integral into Dillo, that's what I consider being monolithic. There is nothing wrong with a distributed design, but my problem with you pushing everything into dpi plugins is that most of those things can be done in seperate modules, meaning that they can be library plugins as wel. It becomes scary when a simple "hello" dpi plugin is 150 lines of code, while the whole ssl support to IO.c is about the same (and much less when there is one IOData/fd). Now you get much more code that all does more or less the same, you may have kept the Dillo core clean and mean, but you get a ridiculous complicated and big plugin system, moving most of the code and functionality outside of Dillo (but in the same time making it twice as big). Now it's very tempting to make a dpi library that implements most used functions, as someone already discovered. What's the next step? Moving all the useful code from Dillo to that library so that even more code is shared I guess (and let Dillo use that library too). What you get is a weird attempt to make something that more or less resembles library plugins, but in, if you ask me, a very awkward way. Of course there are plugins that behave more like daemons, like the bookmark plugin, but then make it a real daemon, so that it can be used by even other browsers. With a flexible and clear internal API most plugins can be done with relative small and simple library plugins, and a few can be implemented as real daemons. >> # Add ftp support. > It has. Using wget for something as basic as ftp in a plugin isn't something that I would call ftp support. Dillo is not a graphical front end for wget, thus I do not think Dillo has ftp support. Wget has. > (this is old problem of sharing a single resource among several clients). An old problem that is solved long ago. Just use inter process communication, like file locks (you can unlock you know). Only what you need to add is an extra fstat to see if the file is edited, and if so, reload the cookies. No big deal if you ask me. > Yes I agree with that reusing dillo's http may come handy. What your mistake is, in my humble opinion, is that you treat https like a seperate protocol, instead of http over another kind of connection. My view is that http is just http over ssl, and that ssl should be a sort of sub-module of IO (or a module that's only used by IO, like dns would be in my way). If you take a look at my patch, you'll see that the changes in http.c and IO.c are minimal, most of the code is at the bottom of IO.c, it could be easily a seperate file (again, only if there is one IOdata per fd, but then the ssl code will be 50 lines or so). Currently proxy support has more impact on http than https support, and you should treat them in a similar way if you ask me. You don't want a seperate plugin or module for proxy http, why do you want one for https? If you mean with monolithic that it's part of the core code, then yes, my way is monolithic, but it's only very little code, modular, and much less monolithic than an embedded splash page. > the details of handling the possible errors should be solved by the client application depending on the protocol and what it is being used for. > So having a generic SSL/TLS gateway may look interesting but it > can get tricky to implement. Not at all. The openssl api supports error callback functions, so the SSL/TLS support in IO can be minimal, if modules need more control they can use the callback functions. All that is needed is a general behaviour that is sufficient in 90% of the cases, and the current implementation does exactly that. Because modules have access to the SSL structure they can have all control they want, if needed. There are more or less 3 types of errors: 1: Connection related errors. (handshake_failure etc) Not much choice how to handle this, retry or abort (all connection related errors, including ssl related things like unsupported something). 2: Bad use of the API. (illegal_parameter) Should never happen with a good implementation. 3: Certificate related errors. (6 out of the 8 errors you listed) Most certificate related things can be done with openssl callback functions, so it's very seperate of the rest, making it easy to add or change later, or to handle it as module. Maybe there's something needed to give the module a chance to do it's certificate (startup) things and setting up the error handling, but not much. All in all IO doesn't have to worry much about all those SSL errors. > It puzzles me: changing the IO engine, Only what will chance is that it does more what it should do, handling IO. > integrating parts of the code that were separated on purpose, That was a misunderstanding, I wouldn't do that, sorry for not being clear enough. > changing the internal API, getting rid of the CCC The current CCC API is not clear or flexible, nor simple. Maybe a more consistent CCC API is possible, maybe no CCC functions at all, I don't know yet, but I'm not simply getting rid of the CCC. > and porting to FLTK, we'd be talking about another browser. Well, porting to FLTK, FLTK has similar aims as Dillo (small and fast), so maybe it was best if it was implemented with FLTK in the first place, but it's too late for that now. I would think twice before porting Dillo to FLTK (making sure that FLTK is alive and actively developed is one thing I would do), but GTK 2 is currently just scary, so FLTK as long term option isn't that bad. Getting libraries smaller is always hard, and GTK 2 is 12 mb now? I also saw the benchmarks, all in all not very encouraging. There is also an existing UTF8 Dillo patch, so maybe it's an option to stick with GTK 1 for a while. I didn't make Dillo, nor do I have much GUI programming experience, so I'm the last one you should listen to when it comes to what widget set to use. But from the networking side, FLTK has a perfect API, only a thin layer on top of select/poll, making it possible to easily add, remove and change the poll events on fds. GTK has an undocumented way of removing fds, can only hope it cleans the io channels up too and so on, but it still has no way to change the events on a fd. GTK has a lot bloat in it's io channel implementation (it's bloat when you don't need all it's features). I looked a bit in GTK's online API, and found the "perfect" replacement for io channels, a bunch of GDK functions that do almost exactly what Dillo needs: http://developer.gnome.org/doc/API/gdk/gdk-input.html It gives us almost the same API as FLTK does, but instead of being a thin layer, it's implemented with io channels, so the bloat is still there, but no way around that with GTK (not without very ugly complicated stuff). Also I think that the hairy bug isn't there, nor will we get another by GTK caused hairy bug if Dillo uses this GDK API, because it does what we want and need, without adding extra complexity like io channels (sure, the bug wasn't GTK's fault you can say, but if the API was clear and simpler, it wouldn't happen). Also FLTK uses internally the same select/poll as for our fds, X communicates through unix sockets, so whole FLTK blocks when nothing happens, while it seems that GTK polls 50 times/second for events or something like that. It's just that I prefer FLTK's way of doing some things. :) > Making a web site (or page for it) requires time, if you're > willing to do that, go ahead but beware that we do not support unofficial patches so you'd have to answer all the incoming questions too. Hmm, a web page, mind if I use the code of the splash screen as a basis? I only want to make an installer so that it's easy for people who, for instance, don't know what cvs is, to get a patched Dillo version. The goal is to have some sort of centralized patch place, with patches that work with eachother and are up to date. It requires time, true, but I'm willing to spend time on Dillo. The installer has no priority though, would rather spend my time to unite the IOData structures, switch to the GDK api, and clean up the https patch for now. All the things I want to have different in Dillo I'm willing to change myself. I'm not saying you should change this or that so or so, I ask if you mind if I change or add some things a certain way, and if you agree that it's better that way. Greetings, Indan (I wonder how many people wil read this 13K monster :)

21 years

Patch for xembed (text corrected)

by Johannes.Hofmann＠gmx.de

Hi, I test xembed support with the claws mail dillo plugin[1] and tabbed[2]. My guess is that the embedder needs to send some X events to the embedded program (dillo in this case) to make it work properly. Even with your patch dillo doesn't resize properly for me when I change the embedding window. I would look into the tabbed source code[2], which is pretty minimal. Cheers, Johannes [1] http://www.claws-mail.org/plugin.php?plugin=dillo [2] http://tools.suckless.org/tabbed/ On Mon, Dec 10, 2012 at 02:12:34PM +0100, podarcis wrote: > Hi all, > > Here is a patch to make embedding dillo into an X-window work. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > diff -r 9bad41ea1dde src/xembed.cc > --- a/src/xembed.cc Wed Dec 05 13:03:04 2012 +0100 > +++ b/src/xembed.cc Sun Dec 09 10:12:36 2012 +0100 > // TODO: Implement more XEMBED support; > > -void Xembed::show() { > +void Xembed::create() { > createInternal(xid); > setXembedInfo(1); > Fl::event_dispatch(event_handler); > diff -r 9bad41ea1dde src/xembed.hh > --- a/src/xembed.hh Wed Dec 05 13:03:04 2012 +0100 > +++ b/src/xembed.hh Sun Dec 09 10:12:36 2012 +0100 > @@ -14,10 +14,11 @@ > > public: > Xembed(uint32_t xid, int _w, int _h) : Fl_Window(_w, _h) { > - this->xid = xid; > + this->xid = xid; create(); > }; > - void show(); > + void create(); > int handle(int event); > + void resize(int x, int y, int w, int h); > }; > > #endif > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > tested with this FLTK program: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > #include <FL/Fl.H> > #include <FL/Fl_Window.H> > #include <FL/x.H> > #include <cstdio> > #include <iostream> > #include <sstream> > #include <string> > > using namespace std; > > > int main( int argc_, char *argv_[] ) > { > Fl_Window dw( 800, 600, "dillo embedded" ); > dw.resizable( &dw ); > dw.show(); > cout << "dw.xid = " << (unsigned long)fl_xid(&dw) << endl; > ostringstream cmd; > cmd << "dillo -f -g " << > dw.w() << "x" << dw.h() << " --xid " << > (unsigned long)fl_xid(&dw); > if ( argc_ > 1 ) > cmd << " " << argv_[1]; > cmd << " &"; > cout << "system '" << cmd.str() << "'" << endl; > system( cmd.str().c_str() ); > return Fl::run(); > } > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > What does NOT work is automatic resizing of the embedded dillo window, > when the size is changed. This would be nice to have. > > I do not know enough of the embedding stuff, but I wonder if the static > int event_handler() ever gets called with type ClientMessage - at least > I could not make it get there.. > > podarcis > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

11 years, 11 months

Re: [Dillo-dev]Dillo on Cygwin

by Jorge Arellano Cid

On Tue, Sep 21, 2004 at 11:32:43AM -0700, Kelson Vibber wrote: > A few days ago I noticed that GTK+ and GLib are now available through > the Cygwin installer, so I started reworking my directions for building > Dillo on Cygwin (currently at > http://www.hyperborea.org/software/dillo/cygwin.html ). I hadn't tried > it since Dillo 0.7.3, so when I built 0.8.2 with the new built-in > libraries, I discovered some problems with DPI. > > First, since Cygwin knows it's running under Windows, it appends .exe to > any executable files it builds. (When you run a command in Cygwin, it > will look for the file as written, then look for it with .exe added -- > so the compiler is really gcc.exe but you can still run it by typing > "gcc".) This includes the DPI plugins, which end up being > bookmarks.dpi.exe, downloads.dpi.exe, etc. This means dpid will not > find them when it looks for available plugins unless you rename them. > > Second, even after renaming them, I can't get any DPI plugins to > actually work. Here is the output from clicking on the bookmarks button: > > Nav_open_url: Url=>dpi:/bm/< > url_str = dpi:/bm/ > Dpi_check_uds: Connection refused /tmp/kvibber-5re3lm/dpid.srs > debug_msg - init_sockdir: The socket directory /tmp/kvibber-5re3lm > exists and is OK > dpid started > Capi_dpi_conn_timeout:: try 1 > main.c:153: get_command: dpid tag is NULL > : main.c:326: main: get_command failed > : bookmarks.dpi (v.13): accepting connections... > [accept]: Software caused connection abort This error message from accept() is weird. > > File permissions on the sockets look the same as they do on a Linux box > (srw-------) > > It may just be something about the way Cygwin handles sockets. Most probably as this scheme works for the *BSDs, GNU/Linux, etc. > Unfortunately I have very little experience with sockets on *any* > platform (and very little experience with C, for that matter) > > Anyway, I figure Cygwin support probably isn't a priority, but I thought > I'd point out the issues in case anyone was interested in tracking them > down. I don't have Cygwin (nor time) here to test it, but surely the Cygwin developers have a clue of what's happening. They probably would appreciate the report too, as they aim to provide the most POSIX like environment I guess. The best way is to test it by stages. The implementation of dpid is not that complex: there's an external daemon process 'dpid' which listens on named sockets and that launches the real dpis when there's activity in the respective named socket. When this happens, the new dpi process "takes over" the socket until it finishes. The details are in doc/Dpid.txt under the sections: "How does it work?" and "dpi service process diagram". Hope this helps. -- Cheers Jorge.-

20 years, 1 month

Re: [Dillo-dev] Some points about the dpi's

by Ferdi Franceschini

On Tue, Aug 19, 2003 at 12:33:53AM +0200, Andreas Schweitzer wrote: > Hi, > > All right, I did it. I made my first dpi ! :-) (heavily That's great, I hope to make a new patch for dpid available soon. > > The second caveat : dillo does not automatically call this plugin > upon such a URL. It is easy to patch dillo, though. Creating a new dpi still requires more effort than it should. > However, this brings me to my questions : > 1) will there be a generic URL->dpi mapping ? > I could imagine that dpid could actually handle that. Yes, but I think you mean URL->SERVICE, a dpi is just an implementation of a service. > I think, one would need to only modify IO/Url.c and > capi.c to simply pass through EVERYTHING to the dpi framework. > However, some "core URL handling dpi's" that will become > part of the dillo package can probably stay hardcoded in dillo. > > 1b) Either way, I am planing on writing a "catch-all-URL handler" > or "fallback handler" or "univeral URL handler" or the like. > It will give the user the possibility to start an external > program for handling certain URL's. > In fact, with my current dpi, this is quite easy > to do :-). OK, but I think we should hold off on 1 and 1b until I make the next dpid patch available. > 2) Does it make sense to write a library for all the dpi's ? > I, for myself, did start simply collecting all the functions > that I found in dpi/ and are used by many dpi's and put them > in a library. Like the various send_stream functions or the > get_attr_value function, or the encoding and decoding functions. Yes, that would be very useful. Your strategy of creating a library of functions which are actually used by many dpis is a good one. > 3) About configuration (and I think I read comments about this > in the code), shouldn't there be only one config file ? > and not dpidrc and possibly different configs for all the dpis ? > maybe even merge cookiesrc with dillorc ? Yes, my next dpid patch gets rid of dpidrc. > I guess some of this (or all of it ?) is being worked on > by some of you. Maybe this mail helps to avoid duplication :-) > > Cheers, > Andreas > > P.S.: I also have some ideas about improving the ftp plugin. There > is a pretty simple ftp library, and I think it does make sense to > actually log in an ftp server and stay logged in for all the operations. > (unlike wget which logs in and out for every file). This is not only > faster but helps with busy ftp sites, too ! Developing the ftp plugin is a high priority and your help here would be appreciated. Best regards Ferdi

21 years, 2 months

[Long] dillo server mode/remote control (was: Re: dillo / time-controlled reloads)

by Melvin Hadasht

Hi, > A simple flag, maybe in the DilloUrl or in the cache entry. In the posted patch, I just added a reload_timeout in DilloUrl and a reload_timeout_tag in BrowserWindow. When viewing a DilloUrl with a non-zero DilloUrl::reload_timeout, BrowserWindow will start a single shot timer which tag is saved in BrowserWindow::reload_timeout_tag. This timer will trigger a reload (as if the user hit the reload button). The reload will restart the timer. If another DilloUrl is viewed, any pending timer is stopped (and the new DilloUrl is again tested for a non-zero DilloUrl::reload_timeout). I also added a_Url_set_reload() to set/unset that reload_timeout. > > - add a "-r, --reload-every" command line option that calls that function. > > In fact, when I finish implementing the "(remote-)command" option, it would be > > something like: "-c open(URL, refresh=60)" (that is if I finally decide that > > supporting commands with more than one argument is worth the work). > > Hmmm, I think a simple cli switch to tell dillo to listen to > the reloads.dpi is enough: > > dillo -reloads Internally, the command line options are translated to a linked list of commands, which are executed by the running instance, or sent to a running server. So I implemented both. The advantage of the "-c" option is that commands could support parameters as in: "open(URL newwindow reload=50)". It adds flexibility. > > > > The first duty is to define what is required for a good, > > > > general purpose, kind of reloading dpi. The next one is to reduce > > > > the features to a minimum working set, then implement! I think it is easier to implement a remote command dpi than implementing a "reload dpi". The "reload" should only be one of the remote commands that a server must understand. > fprintf(reloads_dpi_socket, > "push http://localhost/someurl visible\n"); > > may be all the client program needs to know. Unfortunatly, fprintf does not work with Unix Domain Sockets but with pipes. Pipes have a limitation: if more than a client access to the pipe, the server could get mixed-up commands if the clients commands are larger than a system specific buffer size. For robustness, I will use UDS. If a client program wants to use dillo server capability, then we'd better provide a lib or a small C file. > Note that it may be good to integrate the remote control > functionality into the same dpi (and maybe call it remote.dpi?). Yes, I agree, the reload (and other functions) should be served by the remote control functionality. Whether it should be a plugin, I am not completly convinced, because it adds a little more complexity: At the current state of the dpid, we cannot run more than one dillo server (if we make exclusive use of the dpid framework). This is because for each service, there is only one socket. I think it is more flexible to have the possibility to have different dillo servers, each one with a distinct name provided by the user (or the application). For that, dpid should accept an additional parameter which is used to parametrize the socket name, e.g.: <dpi cmd="start_plugin" msg="dillo" param="cinepaint_help"> dpid will then look if a socket named: "/tmp/$USER-$RAND/dillo-server-$PARAM" ($PARAM being the value of the param tag) exist. If it does not exist, it would start the plugin with a special command line option: dillo -s $PARAM. This will require a way to tell the dpid how to call a parametrized plugin. Thus, relying on dpid to create the socket and run the server plugin would need some changes to dpid. An alternative solution, is to not rely on dpid but on dillo itself to start a server and to create the socket. The socket will be independent from the dpi_dir, and would be /tmp/dillo-$USER-$SERVERNAME. Subsequent communications could still use dpid's I/O functions. > This means adding a simple and useful API for help programs to > use. For instance to let them push new URLs into the same > instance of dillo (and not having to start a new dillo per > requested page). (if the application never starts a dillo instance, then there is no guarantee that there is a dpid running. Or you meant the API should take care of this, too?)

21 years, 2 months

Re: [Dillo-dev] Re: https approaches?

by Jorge Arellano Cid

Ami, > I read the dpi1 document. As far as I can see, it refers to DPI's having a > "scope" which URLs can fall inside of, and this scope is always prefixed > with "dpi:/". Are you saying that: > 1) There is no restriction in the code to the dpi:/ prefix? or, > 2) You have no objection to removing the current restriction to dpi:/? > > If 1, please explain (or point to any documentation/source code that > explains). As near as I can see dillo/src/IO/Url.c:a_Url_get_ccc_funct() > branches to a_Dpi_ccc only if dpi:/ is the prefix. Furthermore, > dillo/src/capi.c:a_Capi_open_url() branches on whether url_str starts with > "dpi:/". > > If 2, do you already have plans in place for maintaining a list of which > plugins handle which prefixes? It is simpler than 1) and 2) ! As SSL has a high priority on my list, it would be a matter of writing an external program that does https (given the URL), retrieves the resource, performs any other required tasks and reports it results somewhere. That is, I'd make all the necessary bindings/extensions in dillo's core to accomodate the plugin. AFAIU, the most basic communications required between dillo and the https dpi are: 1) -> Send the https URL to retrieve 2) <- Maybe make the user confirm the certificate acceptance 3 <- https resource Please inform me about any other required communications. As for developing the prototype, just as stated in the dpi docs. assume you have the answer from dillo and go on! That's all. Hope this helps Jorge.-

21 years, 7 months

https plugin status

by Christian.Kellermann＠nefkom.net

* Jeremy Henty <onepoint(a)starurchin.org> [080315 05:58]: > On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > > > I was wrong, the https filter dpi *is* starting. But, its debugging > > messages don't appear because it sends them to stdout, which dpid > > redirects to the DPI socket. This feels ... somehow ... wrong. > > And so it is! (Patch submitted in a new thread.) After redirecting > the debugging messages to stderr I see: > > [https dpi]: {In https.filter.dpi} > [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue > [https dpi]: { exiting https.dpi} > If you add an additional MSG output you see something like this: [https dpi]: {In https.filter.dpi} [https dpi]: dpip_tag <cmd='open_url' url='https://www.ccc.de' '> [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} dpid_tag looks like there is a missing '. I added Index: dpi/https.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/dpi/https.c,v retrieving revision 1.1.1.1 diff -b -u -p -r1.1.1.1 https.c --- dpi/https.c 6 Oct 2007 22:36:34 -0000 1.1.1.1 +++ dpi/https.c 15 Mar 2008 07:51:29 -0000 @@ -191,6 +191,9 @@ static void yes_ssl_support(void) /*Get the network address and command to be used*/ dpip_tag = sock_handler_read(sh); + + MSG("dpip_tag %s\n",dpip_tag); + cmd = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "cmd"); url = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "url"); http_query = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "query"); I am not sure whether this is really save, is this tag \0 terminated? Nonetheless something is lost on the way... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

16 years, 8 months

Re: [Dillo-dev] HTTPS Patch

by Andreas Schweitzer

Hi, > Sorry for the huge mail. :) And most of it is rather interesting but way more than I know about software design and C :-) > >> # Add ftp support. > > It has. > > Using wget for something as basic as ftp in a plugin isn't something that > I would call ftp support. Dillo is not a graphical front end for wget, > thus I do not think Dillo has ftp support. Wget has. I made a prototype ftp plugin that is based on http://nbpfaus.net/~pfau/ftplib/ Did I post this to the list or only to Jorge ?!? Unfortunately, lately I have a hard time dedicating some quiet time to dillo, so it's still sitting there. But since I could do it, then almost anybody can :-) > > (this is old problem of sharing a single resource among several > > clients). > > An old problem that is solved long ago. Just use inter process > communication, like file locks (you can unlock you know). Only what you > need to add is an extra fstat to see if the file is edited, and if so, > reload the cookies. No big deal if you ask me. AFAIR, the problem is that dillo tries to keep cookies in memory and writes them to disk only when absolutely necesarry. It's a privacy issue. > (I wonder how many people wil read this 13K monster :) Ok, so I went back and read more ;-) But I leave it to the core developers to comment on it. I only found two points I could comment on. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

21 years

Re: [Dillo-dev] Feature request

by TheStar

How would transparency be added, using the X window system, which AFAIK, does not support transparency? I quite like tabbed browsing, except current implementations are very slow (well, they work...) on the other browsers - haven't tried konqueror yet though. As to how these features are developed, I believe that dillo should be developed primarily as a gtk plugin, or set of plugins (such as bookmarks, ftp, and so on), and have multiple 'skins', or program interfaces. Much like gecko in Mozilla, galeon, and the like, or the khtml in safari or knoqueror. This would mean that dillo can potentially become more useful, and would also encourage more innovative ideas as rather than fiddle with code in the CVS, you could just make an app, using the dillo plugin, and you've made a browser! I would also like Dillo to have a windows port - but that's for later when the project matures ;) On Tue, 18 Mar 2003 17:05:24 +0000 (GMT) John Bradford <john(a)grabjohn.com> wrote: > > > All new browsers like Mozilla/Konquerer/Pheonix have the feature > > > Tabbed-Browsing, would be nice if dillo have this, too. > > > > Why oh why? Why don't you people use a window manager that does this? > > Window management is the window managers job for crying out loud. > > > > Try PekWM or PWM as an example of a good, tabbed window manager. > > Tabbed browsing isn't the only way to make more use out of the > available screen resolution. I think we should try to think of new > ideas instead of implementing features just because they are in > another browser. There wouldn't be any point in every single browser > having every single feature implemented exactly the same way, would > there? > > For example, (and I'm not suggesting we add this to Dillo, it would be > the job of the window manager to do it, but it's an example), imagine > that you could vary the transparancy of a window, possibly by using > the wheel on the mouse. You could open a semi-transparent window on > top of the search results from a search engine, click on the links in > the window underneath, and have them load in the top window. Or, you > could start a large page downloading, and browse other pages in > semi-transparent windows above it while you watched the progress of > the download of the large page in the background. > > Or, how about an option to open new windows automatically scrolled > past any initial graphics and large text, and with the main text at > the top of the window? For example, the Dillo home page would load > with the Dillo logo, and 'Welcome to Dillo Project!' text already > scrolled off the screen. This would be useful for people using low > resolutions, or slow machines. > > Another idea, why not have a mode where text links are replaced with a > small, say 160x120 graphic of what that link would look like rendered? > > John. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

21 years, 7 months

Dillo Configuration

by Ringwraith

I'd first like to say thanks for Dillo, its sooo great loading the complete list of CPAN modules in less than 2 seconds, as compared with the nice 5 to 10 seconds with mozilla/firebird :) I do not know if this has been discussed but: One thing I noticed, as Dillo matures, it will obviously need a configuration/preferences menu. I am really starting to get pissed off (pardon lang) at how other browsers use the standard toolkit based widgets to do their configuration. This, IMHO, with the features of today's browsers, clutters up the user interface and causes bloat with the browser. I think having a PURE html interface to doing web browser configuration would do two important things: 1. Gives the flexibility to have a feature rich browser while maintain simplicity. It is a web browser, 90% of the user interface is a web page, so why not make the GUI something the user is familiar with. 2. Reduces bloat. IMHO not so much importantly, 3. Allows for nice customization (themes) of the user interface by someone who knows HTML and vi w/o having to recompile dillo. ;) I am considering to attempt to make a module for the configuration of Dillo that will do this: 1. Configure all aspect of the browser including the (upcoming?) plugin support. 2. Allow pluggable configuration. If plugins have any configurable options (sometimes they do), they will also be configurable using the interface. This module would be accessed through something like: config:// or about:config (i like config:// much better) It would obviously have some security built in so that no one can pull a IE type trick on us and be able to do things they shouldn't. Anyhow this is just a brainstorm, what are your thoughts on doing something like this?

21 years, 1 month

Dillo-dev search results for query "plugin"