Re: Some questions about gtkwebcore and FYI

[Philip Van Hoof <pvanhoof gnome org>]

On Mon, 2006-05-15 at 18:44 +0300, Kimmo Kinnunen wrote:
> Hello Philip,

Hey Kimmo,

I'm adding the tinymail devel mailing list in CC.

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

Okay. So for gtk webcore to be usable the api for adding custom url
handlers would be needed.

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

Right.

> Yes, image view on demand is possible. I don't know how the html mail 
> refers to attached images, 

For example like this:

<img src="cid:01d8-972d069c@a671337e.01c676d4" />

------=_NextPart_001_0191_01C676ED.CBC0BA50
Content-Type: image/png; name="myfile.png"
Content-Transfer-Encoding: base64
Content-ID: <01d8-972d069c a671337e 01c676d4>
Content-Disposition: inline; filename="myfile.png"

BASE64ENCODEDDATA

I can give the api a pointer to the BASE64ENCODEDDATA and I can 'stream'
the actual binary data of myfile.png into the api (typically write calls
in pieces of 4096 bytes, but the api of gtkwebcore shouldn't care about
how much bytes I write per subsequent write call -- theoretically it
should work if I do it byte per byte).

The write call has a prototype like (it returns the actual amount of
written data): 

ssize_t write_the_data (const char *buffer, size_t length);

Imagine this function happening a few times (depending on the size of
the mime-part/attachment). Of course will the pointer to buffer be
increased 'return value' bytes each subsequent call. I can let "buffer"
be base64 or the actual data of what myfile.png would be if say I'd
write it to a filesystem.

In the other direction there's also the 

ssize_t read_the_data  (char *buffer, size_t n);

.. function available for the gtk webcore api. On demand this is
probably the one that would have to be used. This basically means that I
give gtk webcore a pointer to a common 'stream type'. And each time gtk
webcore needs data, it can read it using that method. This would be the
utopia solution for me (and very clean and easy for me to implement).

But it implies that a common stream type or something like that would be
necessary.

Or for example, I give a ptr to 'something' and the api would become:

ssize_t read_the_data  (void *something, char *buffer, size_t n);

That would also work, and could be defined in a .h file of gtkwebcore.

This would basically mean that "I" implement a specific function that is
being called by gtk webcore -> the function that reads data from
'something' (and gtk webcore doesn't care 'how' I do it, it just cares
about 'what' I will fill buffer with -- and it will make sure buffer can
store at least n bytes. I will return how much I've really put in
buffer).

Still with me? ;-)

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

Right. Something like that would be needed. If we'd have something like
this in place, gtk webcore would probably be the next HTML component for
Evolution (as the Evolution team wants to drop their custom GtkHTML).

At some point I might decide to help implementing all this. But note
that my plan/focus isn't implementing a HTML widget. For me viewing HTML
is one of the many features to support, at some point. I'm sure you know
what I mean ;-). Anyway, but I do like to do it in the most perfect way
humanly possible: I really dislike hacks. Especially if they consume my
precious memory.

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

That depends. If gtk webcore is really really intelligent about what
it's showing, it doesn't need the attachment in memory. I can provide
you with a seekable stream that will deliver data that you want to
display. However. I know the reality is that gtk webcore probably
depends on image libraries that expect the image to be in memory. I know
this is me dreaming about the island Utopia.

However .. for attachments that aren't images that are visible in the
HTML document, I'd really like to make sure those aren't in-memory. Not
even when I'm writing them to a target like a file system: Only small
pieces will be in memory per subsequent write call (typically 4096 bytes
but this depends on the 'pusher' -- which is camel, in my case).


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

You don't 'open' it, you 'stream' it from the IMAP service to the target
file system. There's a difference ;-). It's called memory consumption.

> > 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. :)

Ok.

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

Ok.

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

Interesting.

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

Very interesting. I will try to catch up with that discussion soon.

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

Hmm. I don't know. The streaming concept of GtkMozEmbed simply doesn't
work. I have to write the HTML document to a file and load it from that
file. Very ugly.

The current implementation is basically "bling", not something useful.


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