[Webkit-unassigned] [Bug 177932] [GTK] New API to add, retrieve and delete cookies via WebKitCookieManager

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=177932

--- Comment #23 from Mario Sanchez Prada <mario at webkit.org> ---
(In reply to Carlos Garcia Campos from comment #22)
> It's difficult to decide without knowing the main use case of this API. This
> is one of the reasons why we decided not to add new API to WebKit2 without a
> real use case, an application needing that new API and hopefully with a
> patch ready. If the normal use case is getting the list the list of cookies,
> store it somewhere and then delete a particular cookie, then the most
> convenient API is receiving a SoupCookie and of course, compare also de
> value. How is the user supposed to know the domain, name and path without
> getting the list of cookies before? In this use case I don't expect the user
> to create a cookie to delete, but use an existing one.

This is a really strong point and one that made me now lean towards (b) instead, since it's true it's hard to know domain, name and path for a cookie without having retrieved it first. Actually, domain and path you might be able to "guess/generate" them, but there's no way you can know the name to do the match without having retrieved the cookie first.

Besides, as Carlos pointed out to me on IRC, libsoup receives a full SoupCookie as a parameter to delete it from the jar, which is another hint on that perhaps that's the right thing to do.

> If this is not the
> use case, then of course it's more convenient to pass the triplet, but I
> would like to understand the use case.

You kind of convinced me that (b) is the way to go now, but before going all ahead and change the patch now I'll talk to Juan Pablo (or get him to reply here too, if possible) who is the person from Endless' apps team who came up with this requirements, so he might know better what would be best from the application's side.

I think, though, that the API he really needed was add() and get(), as we proposed delete() too just for the API to be complete IIRC, so we might not get more light on that from his side (in which case we might consider simply not adding it, although the API would be a bit unbalanced in that case).

Last, perhaps Leo Ufimtsev might have some opinion on the topic too, since he expressed his interest in this API as well in https://bugs.webkit.org/show_bug.cgi?id=177932#c11.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171120/ec7490e6/attachment.html>