Re: Some questions about gtkwebcore and FYI

[Kimmo Kinnunen <kimmok iki fi>]

Philip Van Hoof wrote:
> Okay. So for gtk webcore to be usable the api for adding custom url
> handlers would be needed.
..
> 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? ;-)

Yeps. The two schemes presented above are insufficient, but basic idea 
is there; the url scheme loader feeds the engine bytestream of data, and 
the rendering engine doesn't care where it is coming from.

I guess the mode of data retrieval is usually as follows.
1) The engine initiates the retrieval of some uri, be it for example 
cid:something. The load context, some sort of resource handle, is passed 
along the request.
2) The loader stack finds the correct loader implementation and passes 
the query and context to that loader.
3) The loader queues the request, possibly initiating network requests
4) After repeating 1-3, the application stack unwinds and execution 
drops to the main loop
5) Data arrives and loader's "data ready" callback is run. This is run 
from mainloop, ie. the network code is integrated to the main loop.
6) The loader calls the "write_the_data" method of the load context
7) 5-6 repeats, until all the data has been processed. loader calls 
"eof" method of the load context

This is a bit of simplification of course, the api needs to have 
concepts for passing around metadata of the url request and state / 
error information. The main point is that API needs a) context 
information about the request, since there will be lots of distinct 
requests b) data is transferred asynchronously c) calling the callbacks 
from the engine needs to happen when engine is not running, ie. from 
main loop context.

So in pseudo-c the gtk-webcore public api looks like this

One has the loader interface which is implemented by the client and 
called by the loader stack..

struct loader {
  something (*new_query)(void *context, uri*, params);
  something (*cancel_query)(void *context);
  /* ... */
}

...some (semi-)global object to which you can register custom loaders..

void register_loader (global_instance*, char* scheme, loader*);

..and functions/methods of the context interface which the 
client-implemented loader calls..

ssize_t write_the_data  (void *context, char *buffer, size_t n);
void eof  (void *context);
void error  (void *context, error);
/* .. */

> 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

I'm not sure what this means.. If it means resources other than images 
referenced from the HTML mail, most likely css or js files: in webcore 
one needs those or at least the representation of those in memory. If 
you mean images not visible in current viewport, I think webcore doesn't 
support delaying image load until they're visible in the viewport. In 
general web case the latter is tricky to get right, as layout depends on 
the image sizes.

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

I'm pretty sure similar streaming can be implemented with Mozilla's C++ 
API..


BR,
Kimmo