Search results for "plugin" - Dillo-dev

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 -------------------------------------------------------

20 years, 4 months

dpid doesn't work if configured with "--program-suffix=-new"

by Detlef Vollmann

Hello, for the time being I'd like to install the current dillo version, next to the old existing one. So I configured with "--program-suffix=-new". Browsing works fine, but plugins (including bm or file) can't be started, as the binary is called "dpid-new" but dillo tries to start "dpid". It probaly wouldn't work anyway as $HOME/.dillo is hardcoded and there's no way to give a separate configuration directory (and sharing .dillo between different version is probably not a good idea). But it would be cleaner not to support "--program-suffix". Detlef

3 months, 2 weeks

dillo-0.8.6-rc5.tar.bz2 is out!

by Jorge Arellano Cid

Hi there, The new dillo-0.8.6-rc5 is ready for download! Get it from: http://www.dillo.org/download/dillo-0.8.6-rc5.tar.bz2 Changes: - Now both download plugins are dillo-cookie aware. - Fixed a bug in memory deallocation (downloads GUI). - "C" locale for log parsing to work on localized systems (downloads GUI). - Now, new downloads appear on top of the list (downloads GUI). - Fixed a segfault for No-Content-Type ans zero lenght resources (cache). As you see, most of it is in the downloads GUI. Nobody complained about the new Content-Type sniffer of rc4, so it remained the same. That's it. Please test and send feedback! -- Cheers Jorge.-

18 years, 7 months

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

On Fri, May 27, 2011 at 12:38:43PM -0500, reza farivar wrote: > On Fri, May 27, 2011 at 10:28 AM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote: > > > On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann > > > > > > > [...] > > > > Did you take special care to compile fltk-1.3 with X11 backend? > > > > If not, you might run the dillo as native Cocoa application. > > > > In that case you were more successful then me. > > > > For me dillo with Cocoa-fltk starts, but does not load any remote > > > > pages. There seem to be severe issues with the way fltk handles events > > > > in the Cocoa case. > > > > > > > > > > Hmm, maybe I should try recompiling fltk with X11 backend...But my > > current > > > native version is so close to working with no problems... > > > > Yes, it's amazing how close it is from working native. > > Are plugins working OK? (e.g. can you browse the filesystem?) > > > > Yes. Well, the only plugin I could see is the save button on the panel, and > it can successfully navigate the filesystem and save a page correctly. > > > > > > Do you know how to use gdb? > > It would be great to know in what functions the busy wait happens. > > It could be a timeout or anything. For this: > > > > gdb ./dillo > > <when locked on high CPU usage, hit Ctrl-c> > > bt > > > > Yes, Here's the result. I tried it a couple of times, and this looks like > the culprit: > > #13 0x000000010007d373 in do_queued_events () at style.hh:554 > #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 > #15 0x0000000100083c6f in Fl::run () at style.hh:554 This gets us on track! Dig... In fltk-1.3-rc6, Fl_mac.cxx, it says: <quote> /** * This public function handles all events. It wait a maximum of * 'time' secods for an event. This version returns 1 if events * other than the timeout timer were processed. * * \todo there is no socket handling in this code whatsoever */ int fl_wait( double time ) { do_queued_events( time ); return (got_events); } </quote> so it looks like when there're sockets to watch, there's a busy wait (because it sometimes work). This is for the FLTK devs to answer. As a wild shot I'd try: Fl_cocoa.mm:680 - time_to_wait = 0.0; + time_to_wait = 0.2; Or set it to always 0.1 and see what happens. -- Cheers Jorge.-

13 years, 5 months

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Russell J. Wood

On Tue, Jun 07, 2005 at 05:13:11PM -0400, Jorge Arellano Cid wrote: > On Sun, Jun 05, 2005 at 12:17:20PM +0800, Russell J. Wood wrote: > > Hi all, > > > > Is it possible to view all request/response headers using DPI? > > That depends on the specific dpi. Please explain it further. Well, it's not for a specific DPI, I would like to know if it's possible to get that information using DPI as if it is, I would like to write a plugin to do it. It's just I didn't see much in the documentation about getting that information. - Russell

19 years, 5 months

Re: [Dillo-dev]mailto: protocol

by Jorge Arellano Cid

On Sat, Oct 02, 2004 at 01:46:46PM +0200, Florent BERANGER wrote: > Hi, > > I didn't see, in docs and config file, how to configure the > mailto: protocol in order to redirect it to a mail client > specified in dillorc config dile. > Does I need a patch for this feature ? This hasn't been implemented so far. It's not hard to do at all. It's just the lack of developers. For instance, provided that "file:" URLs are sent to a dillo plugin (dpi), the same can be done for "mailto:". Even more, it would be much simpler than with "file:". *sigh* -- Cheers Jorge.-

20 years, 1 month

Ignore a command line option (for Mac OS bundles)

by obeythepenguin＠gmail.com

On Sun, 05 Jun 2011 15:54:56 -0400, corvid <corvid(a)lavabit.com> wrote: > reza wrote: >> Now most of the plugins seem to work, at least bookmarks work fine. >> >> There is still a problem remaining though. In the target machine, I >> cannot >> open sites that require SSL (for example www.gmail.com, >> mail.yahoo.com) I'm >> not sure why it happens. Is there any library that helps in SSL >> connections >> that I forgot copying over? > > openssl? libssl and libcrypto (and Dillo needs to be compiled with --enable-ssl) ~Benjamin

13 years, 5 months

Re: [Dillo-dev] HTTPS Patch

by Jorge Arellano Cid

Hi, On Thu, 30 Oct 2003, Indan Zupancic wrote: > Updated the diff, gcc 2.x should work now, link is still > http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz Here go my comments. (An important part of the answer is in this email: http://article.gmane.org/gmane.comp.web.dillo.devel/1407 ) > It would be nice to get some feedback from the Dillo developers, I'd like > to know what they think should change before the code is good enough to go > into the official Dillo, and if they even consider that of course. Of course it is considered! (see above URL) > I have plenty of ideas, but most of them aren't feasible without merging > the two IOData structures (now there is one for the read part, and one for > the write part, why, I don't know, doesn't make things simpler), 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. > doing > that makes it much easier to do certain, more complex things that need to > have all the fd related info in one place, like ssl, connection caching > (currently Dillo opens and closes a connection for each action, although > it seems to work well, it's still more efficient to keep connections open > longer, especially with slow/bad network connections), "keep alive" (to > avoid timeout problems in ssl, quite annoying when you're taking too much > time typing an email), simple ftp support, etc. Currently dillo does that. Every time you add a bookmark, dillo and the server chat a little while before adding it (with connection caching). > I know that the Dillo developers want to implement most "extra" features > like https/ftp/bookmarks/etc as plugins, but I think it's beter to > implement the features that are used a lot, or just very important, like > https and ftp, natively in Dillo with a small implementation. The overall > code is most times smaller too, can say that Dillo is just 300 K, but it > would be a bit weird if the plugins together are bigger than Dillo after a > while. https took around 2 Kb, I think I can implement basic FTP (and > possibly ftps) in about 15 K, using no external ftp library or program > (hopefully 10, worst case 20K). That is a design decision: Monolithic vs Distributed. Is hard to have a definitive choice. Dillo follows the distributed approach. > If you let me loose on Dillo's code then this is what I would do: > > # Cleanup the IO engine, one IOData per fd. Could be. > # 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. > # Add ftp support. It has. > # Add file upload support in html forms. Agreed. > # Add connection caching to IO. It has. > # Auto keep alive like behaviour for ssl connections. > > # Maybe always ACCEPT_SESSION for cookies when they come via a https > connection. Could be. > # Get rid of the ccc construction, or change it so that it behaves more > logical. My opinion is that you should have either a clear unique API for > each module, or one general API that is the same for each module. > Something in between like the current ccc functions is only confusing (if > you want a chain like behaviour, then use function pointer stuctures or > something). The CCC is all about parallelism and error handling. It is the supporting core of the application. Not easy to substitute. > # When changing the internal API anyway, making shared library plugins > possible too, at least for the IO part (maybe ftp library plugin as proof > of concept). Changing the internal API... > # Get rid of the splash stuff, move it to an external html file that is > opened by default when nothing else is opened. Currently the splash screen > is even opened when you do "dillo http://site.org". Loading a file is > almost as fast as the build in splash screen. Removing it makes Dillo > smaller (about 10 K), simpler and lets people make their own startup pages > (for instance a to hd saved google.com) 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. Having a dillorc option to replace the Splash with a local file may be handy though. > As you could notice, I'm mainly interested in the internet/IO part, > graphical stuff doesn't attract me much. If it did, I would help/start > porting Dillo to FLTK. If Dillo decides to go with GTK 2 then I will > probably stop using it :(. It puzzles me: changing the IO engine, integrating parts of the code that were separated on purpose, changing the internal API, getting rid of the CCC and porting to FLTK, we'd be talking about another browser. > I don't have enough faith in GTK2, it's already > too big (and I saw the test results). If you have GTK 2 running anyway it > doesn't matter much if you run Dillo too of course, but that's the case > too with all those KDE/Gnome programs. IMHO, you should look at all the > code that a program uses, including the one in dependencies. I prefer a > program that has it's own small and efficient implementation of something > to one that is smaller but uses huge libraries. Agreed. The GTK2 issue is under study now. > I'm also thinking about making a Dillo installer (sh script) that > downloads and installs the cvs version of Dillo and applies the patches > the user wants. This needs some coordination, I saw links to other Dillo > patches, but I don't know if they are up to date, nor if the maker is > willing to keep that so. Currently the only patches I know that are up to > date are Frank's patches and my own https patch. 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. Cheers Jorge.-

21 years

Re: [Dillo-dev]https

by Garrett Kajmowicz

> Any more news here? > Things seemed to be going rather well a month back :-) I sent in a patch a month or so ago, but I don't know if there is much more to be done at this stage. Things seem to work well, and most error conditions notify the user specifically. Those that don't give a generic error message (very unlikely cases). I'm not sure where to go from here. The dpi infrastructure makes it hard to do some things, but I guess it might be possible to convert the plugin to a process. Other than that, I don't know if there is much more that needs to be done. - Garrett

20 years, 2 months

dillo-0.8.6.tar.bz2 is out!!!

by Jorge Arellano Cid

Hi there, dillo-0.8.6.tar.bz2 is finally ready for download. Get it from: http://www.dillo.org/download/dillo-0.8.6.tar.bz2 The announcement will be made hopefully after the RPMs and DEBs are ready. Package maintainers, please let me know when ready. The graphical downloads plugin is the recommended choice for precompiled packages. IMPORTANT NOTE: FLTK2 r4898 or less is recommended. Later snapshots behave unstable. You have been warned. How to get FLTK2: From scratch from svn: svn co -r 4898 http://svn.easysw.com/public/fltk/fltk/trunk/ fltk to an existing svn tree: svn update -r 4898 Please send some feedback. This is the same rc5 tarball (with a 0.8.6 label), but you never know! :-) -- Cheers Jorge.-

18 years, 6 months

Dillo-dev search results for query "plugin"