|author||Michael Drake <email@example.com>||2017-06-17 10:14:41 +0100|
|committer||Michael Drake <firstname.lastname@example.org>||2017-06-17 10:14:41 +0100|
Docs: Update architecture with plan for client-started fetches.
1 files changed, 28 insertions, 7 deletions
diff --git a/docs/architecture.md b/docs/architecture.md
index 26232c9..63142fe 100644
@@ -152,14 +152,35 @@ For a client initiated fetch of CSS, the selection context is updated when
we have fetched the style sheet, and LibNSLog is informed.
For a LibNSLayout initiated fetch, LibNSLayout creates a `nsl_resource_t`
-and passes a pointer to to to the client, along with the URL to fetch.
+and passes a pointer to the client, along with the URL to fetch.
The `nsl_resource_t` is opaque to the client. When the resource is fetched,
the client calls a callback passing, the `nsl_resource_t`, and a pointer to
the client handle for the resource (`hlcache_handle`, in NetSurf). Then
`LibNSLayout` can set the pointer to the client resource handle inside the
-`nsl_resource_t`, and the pointer will be used to ask the client about e.g.
-intrinsic dimensions. The pointer to the client handle will also appear in
-the render list that is given to the client for display.
-> **TODO**: How to do fetches started by client for e.g. images, that
-> LibNSLayout needs to know about.
+`nsl_resource_t`, and the client handle pointer will be used to ask the client
+about e.g. intrinsic dimensions. The pointer to the client handle will also
+appear in the render list that is given to the client for display.
+For fetches started by client (for example, replaced-element images) that
+LibNSLayout needs to know about, the client starts the fetch when it gets
+the DOM event about the newly added/modified IMG element, it then informs
+LibNSLayout of the updated DOM node, passing the client handle for the
+resource. Since there is a non-null client resource handle, LibNSLayout
+knows it's a replaced element, and can ask the client for intrinsic dimensions.
+ nslayout *layout,
+ dom_node *element,
+ nsl_resource_t *replaced,
+ nsl_resource_type_t type);
+The `nsl_resource_type_t` would be a client defined enum allowing the client
+have different handle types for different things, e.g. image resource handle,
+and form button handle. The type would be passed back with the resource.
+The client is responsible for calling a function to tell LibNSLayout what
+the intrinsic dimensions are for a resource, if applicable. It can do this
+once it has the information (e.g. once it's fetched and parsed the header of