Search results for "plugin" - Dillo-dev

https plugin status

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:21:23PM +0000, Jeremy Henty wrote: > On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote: > > > > [Jeremey wrote] > > > Or maybe Capi_url_uses_dpi() should be checking for "https" and > > > *not* adding the "proto." prefix? > > > > "proto.https" is the right patch. > > OK, what about my patch to redirect MSG debugging messages from stdout > to stderr? Is that correct? Dpi programs are reading and writing from the stdin descriptor, and all of them send debug messages to stdout. I think this is correct, or at least standard by now. -- Cheers Jorge.-

17 years

DHT based search engine

by Schimon Jehudah

Greeting! I suppose that people here know BBS, P2P, Kad, eD2k (eDonkey2000), Gnutella, G2, DC, ADC etc. Whlie I have wrote an email concerning to a search service provider, I have thought of the DHT technology which could make search engines built-in. > Perhaps Dillo should have a built-in DHT-based search interface (such > as of Kad of eMule) that would communicate with instances such as > 4get, Marginalia, MetaGer, SearxNG, Wiby, YaCy etc. What do you think of this idea? We can start by providing a plugin and later decide whether to make this a part of Dillo. I can write a plugin in Python, if you want me to. Kindly, Schimon

2 months, 1 week

youtube-dl

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > Maybe it would be nice to have the dpis able to register interest in > > resources meeting certain criteria or something. Or maybe the trick > > is to simply :) implement the NPAPI. > > ??? What is this "NPAPI" of which you speak, Earth being? :-) I > guess I've not been keeping up. Sorry, I wrote more and then I guess I trimmed it down too much. Netscape Plugin API The mighty wikipedia claims: The following web browsers support NPAPI plugins: o Epiphany o Google Chrome o Konqueror o Mozilla project applications, including o Camino o Firefox o Mozilla Application Suite o Seamonkey o Netscape Navigator and Communicator o Opera

14 years, 9 months

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi Christian, On Sat, Mar 15, 2008 at 07:32:56PM +0100, Christian Kellermann wrote: > Hi Jorge, > > * Jorge Arellano Cid <jcid(a)dillo.org> [080315 18:58]: > > Sorry for the late answer, but I've had little spare time, > > and several topics to answer. > > > > Probably you have already read: > > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… > > > > an got some info from there. > > Yes, thanks for the hint, it was insightful. I have spend a few > thoughts on the SSL issue and I'd like to hear your opinion on it. Funny how this makes me wonder whether you read the rest of my comment on this same email: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/003928.html :-) There I suggest for an internal implementation, but, I know it can also be done with a server dpi: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-October/003237.html > The most work that still needs to be done is to handle certificates > and the user interaction required to make it usable. Garret wrote a good part of the certificate handling, you will find that code inside the plugin. > The user needs > to add trust values to certificates and to add or remove them > offline. I think this can fit well into a server dpi. Adding and > deleting bookmarks could be done similar to handling bookmarks. Yes. > Which might be a bit rough but is independent on fltk widgets. I > do think that we already have enough dialog types in dillo. Hard > coding the certificate handling would not make the situation any > better. That's why I implemented the dialog request option in dpip. This is, a dpi can ask dillo to pop a dialog and to send back the answer. This was working in dillo-0.8.6, and got a bit trimmed after the port. It should be simple to enable it again. > > Also I can imagine this plugin to handle client certificates which > I do believe will become a more common requirement for certain > applications in the future. Adding secure storage capabilities will > be easy. Also people will have the chance to write some "bridging" > plugin that extracts the needed data from existing storage sources > elsewhere, i.e. certificate servers,... I like the ide of an https dpi server. What I don't know is whether the current and future requisites for it to work, will make it harder to mantain in the future. At the present day both options (server and internal) look similar. > Handling this all internally means that we put functionality into > dillo that are needed for, but basically have nothing to do with > browsing. As I have grasped the spirit of this project this may not > be the way to go. A nice thing about handling https internally is > the opportunity to reuse an established connection for more than > one request, which might speed up transfers significantly. > > But on the other hand couldn't this be done by dpid for all filter > plugins? For all filter plugins, not. They were designed as one request, one answer with EOF and close as an important part of the process. OTOH, dpi servers were designed to do that. > Dpid can keep them alive as long as the following requests > belong to the same URL, then closing the connection after a timeout? > > I am sorry if this has been already decided on before. These thoughts > were rumaging aroung my head all day now... I hope these lines help. -- Cheers Jorge.-

17 years

https plugin status

by place＠gobigwest.com

Jeremy wrote: > 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} > > which at least gives some idea of what is going wrong. It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead of "https"...

17 years

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by obeythepenguin＠gmail.com

Johannes wrote: > I doubt it's worth making the current experimental HTTPS plugin > IPv6 ready. > We will need a more robust HTTPS solution at some point. > Cheers, > Johannes Why not just reuse the existing HTTP code? *cough* http://dillo-win32.sourceforge.net/patches/07-dfcntl.diff http://dillo-win32.sourceforge.net/patches/08-dsock.diff http://dillo-win32.sourceforge.net/patches/17-https.diff Just add some warning dialogs and you've got everything the plugin offers, plus greater efficiency, code reuse, IPv6, etc. (Not to mention, it's thoroughly tested and quite stable on Linux, BSD, that other OS with 99% market share, etc. I use it myself every day.) Anyway, all my code's still there if you're interested. Cheers, ~Benjamin

13 years, 3 months

Question about local file browsing

by rogutes＠googlemail.com

Benjamin Johnson (2011-04-09 14:17): <...snip...> > One other thing that concerns me: a Windows user might start Dillo, > see a bunch of unfamiliar DPI programs running, and worry that it's > some kind of virus/spyware infection. Even if someone explained > that it's just part of the browser, they might not be convinced, > since -- say -- Firefox doesn't start all that stuff in the > background. Spyware is increasingly a very real and very serious > concern, so many users are justifiably suspicious of anything even > remotely out of the ordinary. Firefox does start some stuff in the background (plugin-container.exe, since Firefox 3.6.4). Though your point seems to be valid, at least on Windows: http://google.com/search?q=plugin-container.exe -- -- Rogut?s Sparnuotos

13 years, 11 months

XMPP PubSub Plugin

by Schimon Jehudah

Good day, to one and all! My name is Schimon, I am a pianist, attorney at law, and I also work on software that mainly involve the technologies of Syndication and XMPP. My current intention, is to design an XMPP client, based on Slixmpp, to allow Dillo to interact with Atom Over XMPP (XEP-0277 and XEP-0472). Atom Over XMPP specifies storage of textual content (be it text or HTML) on XMPP PubSub nodes. It is useful for publishing (see Libervia, Movim, Rivista XJP), annotating resources (see Blasta) and for any sort of mean which may require textual content. References: https://blasta.woodpeckersnest.eu/help/about/xmpp/atomsub https://blasta.woodpeckersnest.eu/help/about/xmpp/pubsub Projects: https://schapps.woodpeckersnest.eu/blasta/ https://schapps.woodpeckersnest.eu/rivista/ I intend to utilize the Python computer language for this task. Any help, encouragement, and especially accompanying (not in the musical sense) my efforts be welcome. This is my first time which I intend to collaborate with Dillo developers, and I am excited by this opportunity. Kind regards, Schimon

4 months, 4 weeks

Patch for xembed updated

by higuita7＠yahoo.co.uk

Hi > I don't know if the claws plugin is still used by anyone, but I > don't want to remove the code, that proved to be working. I use both dillo and claws-mail, where i load the dillo plugin... so, yes, it is still used, at least by me :) Thanks for dillo :) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

12 years, 2 months

https plugin status

by jcid＠dillo.org

Hi, Just a follow up on https dpi: > [place wrote] > It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead > of "https"... Yes this is a bug from the latest big dpi upgrade (generic dpi protos). > [Jeremey wrote] > Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* > adding the "proto." prefix? "proto.https" is the right patch. > [Christian wrote] > But what is supposed to be working atm? Really basic, if you can see: https://www.rapidssl.com/test/rapidssl.htm that's all. BTW, with place's patch, I can also see: https://www.ccc.de > [Jeremey wrote] > Getting https working would greatly reduce the number of times I run > Firefox! I thought many https sites needed javascript to work. _Please_ correct me if I'm wrong. :-) > [...] With regard to the missing dialog function, you may get a very good idea by looking at its implementation in dillo-0.8.6. That's what I'd do to answer if I had the time now. -- Cheers Jorge.-

17 years

Dillo-dev search results for query "plugin"