[Fwd: Re: Some questions about gtkwebcore and FYI]

[Philip Van Hoof <spam pvanhoof be>]

FYI

-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

--- Begin Message ---

• From: Kimmo Kinnunen <kimmok iki fi>
• To: Philip Van Hoof <pvanhoof gnome org>
• Subject: Re: Some questions about gtkwebcore and FYI
• Date: Mon, 15 May 2006 18:44:13 +0300

Hello Philip,

Would it be(come) possible, using the standard gtkwebcore api, to
disable loading images, stream HTML 'and' image-data in and to disable
javascript?

Certainly this is possible. Gtk-webcore was/is based on WebCore-145+, which was already used in Apple's Mail client. All needed hooks are in the engine. Disabling image loads and javascript might even be connected in the gtk-webcore public (gobject c) api, I don't quite remember did I completely implement that one. It is not possible to write custom url handlers with the public API. There is few url handlers in NRCit C++ code, namely ones for file:// and http://.. One should implement a public api for this and then hook it up to the NRCit loader stack..

I'm planning to add support for gtkwebcore to tinymail. However,
tinymail does not have the attached images (mime parts in e-mail
terminology) of a message stored on a disk nor available on a url. And
the ones that are located on some url shouldn't be loaded (for well
known anti-spam reasons).
The gtkhtml component was once hacked for evolution and does have these
features. But I'd prefer to use for example gtkwebcore.

Yes, so the basic thing is, that custom url handlers can be written and above settings can be set in the rendering engine, so that certainly this kind of feature can be implemented. The biggest part is defining the public gobject c api (maybe with GInterface or some signals which carry ids in args), and then implementing in NRCit C++ side the file hooks that connect the public api to webcore.

The reason why it would be great to have the possibility to 'stream'
data rather than putting it on a filesystem and loading a "file://" url
is that with proper streaming I can make the system in such a way that
unused mime-parts are never downloaded from the e-mail service nor ever

Yes, image view on demand is possible. I don't know how the html mail refers to attached images, but anyway the drill is always the same. Process the html and filter unsecure stuff, convert img/css/etc urls to some custom url scheme, for example 'attachment:'. Then feed the data (html mail) to the engine. If the image viewing is on, the engine issues the load to loader stack, where there can be custom loaders implemented through the public API. The loaders then can do what ever they like, for example stream IMAP data through base64 encoding filter back to the engine.

> So if it would
> be possible not to load the mime parts in the memory nor to download
> them from the service: I wouldn't.

In any case, if you are showing the attachments, you of course need to have the attachment in the memory. In practice the data will be there many times, usually the minimum is that you have the compressed image and the drawn image.

Imagine 'viewing' an E-mail with a 10mb attachment on a device that has
only 15 mb ram: Using streaming I can stream that attachment piece by
piece to the target filesystem.

Well, I'd say it'd be challenging to open 10mb attachment on device with 64mb or 128mb ram. With 15mb ram linux device you cannot even run programs linking to webcore. But anyway, I get your idea.

Oh and, for your information. The current release doesn't compile on a
Dapper:

Yes, there's some C++ related compile errors which have been fixed in the cvs version. They're due to recent g++ being more strict or c++ std changes.. I don't know if the gtk / gdk / glib / gobject parts compile on Drapper, I would expect not, since lots has happened with the libraries during the inactivity perioid. :)

I doubt that you should try to use gtk-webcore as-is, because it's pretty unstable. It's based on ages old WebCore version and the code I wrote (NRCit) is pretty much crap. In order to have even moderately secure mail client with webcore rendering html mail, one would first need to re-port the WebCore from webkit.opendarwin.org svn and then re-write the component equivalent to WebKit/NRCit..

I even have some unfinished code related to that. It was left unfinished because I lost interest in tracking apple changes and writing the dull GObject classes / interfaces by hand.

There's some activity in webkit community to port the recent webcore of the apple's webkit to gtk/linux. The port has been initiated by this one guy, but nothing has been released AFAK. Of course after webcore port there's the job of writing webkit equivalent code (I wrote the NRCit, the part that sucks probably the most in gtk-webcore) which has not started at all. So it'll take a while before this can be used.. If you are interested, check out webkit.org and there the mailing-lists.

I saw from your blog that you're already working with mozembed.. That's good alternative also, and certainly more stable than my gtk-webcore work =)

BR,
Kimmo

--- End Message ---