[webkit-gtk] WebsiteDataStore API proposal for handling data

[Carlos Garcia Campos]

El lun, 22-06-2015 a las 12:29 +0200, Carlos Garcia Campos escribió:
> As I said in the other thread, the WebsiteDataStore class also allows 
> to
> retrieve origins/domains with website data and delete website data 
> for
> any particular origin/domain.
> 
> The internal API uses the same methods for all kinds of data (local
> storage, disk cache, memory cache, etc.), using flags to specify the
> kind of data you are interested in. So, it's just 3 methods:
> 
> void fetchData(WebsiteDataTypes, std::function<void 
> (Vector<WebsiteDataRecord>)> completionHandler);
> void removeData(WebsiteDataTypes, 
> std::chrono::system_clock::time_point modifiedSince, 
> std::function<void ()> completionHandler);
> void removeData(WebsiteDataTypes, const Vector<WebsiteDataRecord>&, 
> std::function<void ()> completionHandler);
> 
> This requires a WebsiteDataRecord struct to know which type the 
> result
> refers to. So, we could do something similar adding a boxed type for 
> the
> WebsiteDataRecord struct and just two methods fetch_data and 
> remove_data
> (I wouldn't expose the remove_modified_since for now). This API makes 
> it
> very easy to add new data types, since it would be a matter of adding 
> a
> new flag, and it could be more efficient when getting or removing
> different kinds of data at the same time. However, I think this kind 
> of
> single API for everything is usually more confusing, and more 
> difficult
> to use (and requires the extra boxed type), and operations over 
> website
> data are not that frequent to require to be optimized. So, an
> alternative could be to use a different method for every kind of 
> data.

I'm changing my mind here . . . Now that I have started to implement
the API, and think about how to use that in ephy, I think that the
common use case is indeed getting all the website data. And this API
makes the common case painful, you need to call 7 async methods, and
wait for them all to fill the UI. So having methods that receive the
website data to fetch/delete as a flags parameter allows both cases,
you get the data individually, or all together in a more convenient
way. The only problem is that we need a boxed type for the results, to
know which type of website data every result refer to, and also because
some data types work with security origins, and other with domains.
This could be something like this:

void webkit_website_data_manager_fetch (WebKitWebsiteDataManager *manager,
                                        WebKitWebsiteDataFlags    types,    
                                        GCancellable             *cancellable, 
                                        GAsyncReadyCallback       callback, 
                                        gpointer                  user_data);
GList *webkit_website_data_manager_fetch_finish (WebKitWebsiteDataManager *manager,
                                                 GAsyncResult             *result, 
                                                 GError                  **error);

void webkit_website_data_manager_delete (WebKitWebsiteDataManager *manager,
                                         GList                    *sites,
                                         GCancellable             *cancellable, 
                                         GAsyncReadyCallback       callback, 
                                         gpointer                  user_data);
gboolean webkit_website_data_manager_delete_finish (WebKitWebsiteDataManager *manager,
                                                    GAsyncResult             *result, 
                                                    GError                  **error);

void webkit_website_data_manager_clear (WebKitWebsiteDataManager *manager,
                                        GCancellable             *cancellable, 
                                        GAsyncReadyCallback       callback, 
                                        gpointer                  user_data);
gboolean webkit_website_data_manager_clear_finish (WebKitWebsiteDataManager *manager,
                                                   GAsyncResult             *result, 
                                                   GError                  **error);

We would always work with a list of the boxed type that could be
something like:

WebKitWebsiteDataType webkit_website_data_get_data_type (WebKitWebsiteData *website_data);
WebKitSecurityOrigin *webkit_website_data_get_security_origin (WebKitWebsiteData *website_data);
const gchar *webkit_website_data_get_domain (WebKitWebsiteData *website_data);

The main problem of this API is that get_security_origin and get_domain
depend on the data type, so the user needs to know which types work
with origins and which ones with domains. Of course we can just
document that. We can also make WebKitWebsiteData an abstract class and
add two derived classes (WebKitWebsiteOriginData and
WebKitWebsiteDoaminData), then the user only needs to ask the object
type (using the IS macros). Maybe that's too much for so simple
classes. We could also add is methods to query the object
webkit_website_data_is_origin and webkit_website_data_is_domain instead
of assuming that get_origin returning NULL means it's for a doamin and
get_domain returning NULL means it's for an origin.

Opinions?
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20150731/76c42601/attachment-0001.sig>