El lun, 22-06-2015 a las 07:31 -0500, Michael Catanzaro escribió: > On Mon, 2015-06-22 at 12:29 +0200, Carlos Garcia Campos wrote: > > The methods to delete data would be similar, one for every type > > receiving a list of domains or origins, and another one for every > > type > > to remove all data (like the cookie manager). I'm not sure if the > > remove > > methods should also use the async pattern approach. The internal API > > has > > a completion handler, but just as a notification, it doesn't say if > > the > > removal was successful or not, for example. Users could use the async > > ready callback just to update the UI after a removal, for example. > > Cookie manager doesn't have the callback either, so not using the > > async > > pattern would be consistent with cookie manager. > > I think the async pattern is important, otherwise there's no way to > e.g. show a spinner while the operation is taking place, or know when > it's complete. This is a problem in Epiphany right now; when you hit > Clear Personal Data, the dialog immediately and the only way the user > can know anything happened is to listen to the sound of the hard disk > writing.
This is a good point, my ssd doesn't make noise, so we need a ready callback to add a spinner or busy cursor. > I wonder why the internal API doesn't have any error detection. We > should return a GError regardless, even if we can't set it currently, > so that we can add errors in the future. Agree. > > So, in summary, I think we have at least the following options: > > > > a) Use a single API for all with flags like the internal API > > b) Use a different method for every data type > > c) Use different method for every group of data types > > d) Use a manager class for every group of data types and move > > WebKitCookieManager too. > > > > Any other option? Any other thing I haven't considered? Which one you > > think is better? > > Clearly (d) is the worst option, to add a bunch of classes to the API. > > I would do (b) since it's easiest to use, but (c) looks good too. My main concern with c) is if we eventually need a method specific to a type that doesn't make sense for the group or that can't implemented for other types of the group. By the way, I used webkit_website_data_store_ everywhere, but it would be webkit_website_data_manager_ > _______________________________________________ > webkit-gtk mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-gtk > -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
