Re: Some questions about gtkwebcore and FYI

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

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]