<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [GTK] Add API to WebKitWebsiteDataManager to handle cached data"
   href="https://bugs.webkit.org/show_bug.cgi?id=146589#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [GTK] Add API to WebKitWebsiteDataManager to handle cached data"
   href="https://bugs.webkit.org/show_bug.cgi?id=146589">bug 146589</a>
              from <span class="vcard"><a class="email" href="mailto:cgarcia&#64;igalia.com" title="Carlos Garcia Campos &lt;cgarcia&#64;igalia.com&gt;"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
        <pre>(In reply to <a href="show_bug.cgi?id=146589#c6">comment #6</a>)
<span class="quote">&gt; Comment on <span class=""><a href="attachment.cgi?id=257556&amp;action=diff" name="attach_257556" title="Rebased patch">attachment 257556</a> <a href="attachment.cgi?id=257556&amp;action=edit" title="Rebased patch">[details]</a></span>
&gt; Rebased patch
&gt; 
&gt; View in context:
&gt; <a href="https://bugs.webkit.org/attachment.cgi?id=257556&amp;action=review">https://bugs.webkit.org/attachment.cgi?id=257556&amp;action=review</a>
&gt; 
&gt; Unofficial +1 on the API changes from me.</span >

Thanks for looking at it.

<span class="quote">&gt; I think it would be helpful to add to the documentation of
&gt; WebKitWebsiteDataManager a short description of the difference between the
&gt; memory cache and the disk cache. (I presume the memory cache is the page
&gt; cache, and the disk cache is the network cache?)</span >

Memory cache is not the page cache is the memory cache, used to store any cacheable resources in memory, and disk cache is the HTTP disk cache used by the networking process.

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitSecurityOrigin.cpp:30
&gt; &gt; + * &#64;Short_description: A security boundary for Websites
&gt; 
&gt; I would rather say &quot;websites&quot; in lowercase.</span >

Ok.

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitSecurityOrigin.cpp:35
&gt; &gt; + * by Websites. An origin consists of a host name, a protocol, and a port
&gt; 
&gt; Same.</span >

Ok.

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitSecurityOrigin.cpp:55
&gt; &gt; +    CString host;
&gt; 
&gt; I don't understand the value of duplicating protocol and host here, when
&gt; they are already stored in the WebCore::SecurityOrigin. It's also a bit
&gt; confusing that these are initialized in getters.</span >

This is a common thing we do in the API just to make it more convenient to use. The host and protocol are stored in WebCore::SecurityOrigin as String, but all our APIs return always string in utf8 (like all other GNOME platform APIs). If we return the converted string directly, the returned value should be freed by the user. So, we cache the converted strings to be able to return a const char *, and we do that only on demand, so if you never call get_host we don't have a cached value for nothing.

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitSecurityOrigin.cpp:63
&gt; &gt; +    WebKitSecurityOrigin* origin = g_slice_new(WebKitSecurityOrigin);
&gt; 
&gt; I think we should stop using GSlice and just use plain new/delete instead. I
&gt; base this off of a comment in the GNOME memory management programming guide:
&gt; &quot;we don’t want to encourage [use of g_slice_new]. GLib developers are moving
&gt; towards deprecating it due to its performance slipping significantly behind
&gt; the libc allocator’s on Linux in recent years.&quot; That is literally a comment,
&gt; as in a commented-out section of the guide, so it doesn't show up on the
&gt; actual website, but it's there to discourage people from adding guidance on
&gt; GSlice:
&gt; <a href="https://git.gnome.org/browse/gnome-devel-docs/tree/programming-guidelines/C/">https://git.gnome.org/browse/gnome-devel-docs/tree/programming-guidelines/C/</a>
&gt; memory-management.page#n22</span >

Good point, didn't know that.

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitSecurityOrigin.cpp:77
&gt; &gt; +    ASSERT(origin);
&gt; 
&gt; When you would write an assertion like this, I think it's better to pass by
&gt; reference instead. I think we've been trying to avoid pass by pointer except
&gt; in C API and when the pointer is expected to be null.</span >

WebKitSecurityOrigin is a boxed type not a C++ class, we always use pointers with GObjects or boxed types. That ASSERT is equivalent to the g_return macros used in public methods, but in this case I used ASSERT because it's a private method.

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitSecurityOrigin.cpp:166
&gt; &gt; + * Returns: The host of the #WebKitSecurityOrigin.
&gt; 
&gt; This needs a (nullable) annotation, or (allow-none), since you decided to
&gt; return nullptr if the string is empty.</span >

I thought nullable/allow-none was assumed for char *, I think we don't use that in any of our APIs, we will have to update them all.

<span class="quote">&gt; Did you see
&gt; <a href="https://blogs.gnome.org/desrt/2014/05/27/allow-none-is-dead-long-live">https://blogs.gnome.org/desrt/2014/05/27/allow-none-is-dead-long-live</a>-
&gt; nullable/ and continue to use (allow-none) for compatibility with old
&gt; gobject-introspection?</span >

No.

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitWebsiteDataManager.cpp:512
&gt; &gt; +                origins = g_list_prepend(origins, webkitSecurityOriginCreate(origin.get()));
&gt; 
&gt; And the same origin won't ever be in multiple records? (Same question
&gt; applies to the case of the memory cache.)</span >

That could probably happen when you call fetchData with more than one type, but we always use fetchData with a single type. 

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitWebsiteDataManager.cpp:524
&gt; &gt; + * &#64;error: return location for error or %NULL to ignore
&gt; 
&gt; Shouldn't this be annotated (optional) or (allow-none)? Same for all the
&gt; other error parameters in this file.</span >

I thought that GError ** was handled automatically too.

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitWebsiteDataManager.cpp:651
&gt; &gt; + * %WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS process model, an empty list will
&gt; 
&gt; This is a comma splice; you can fix it by changing the comma to a semicolon,
&gt; or by splitting it into two sentences if you don't like semicolons.</span >

I don't mind to use ;

<span class="quote">&gt; &gt; Source/WebKit2/UIProcess/API/gtk/WebKitWebsiteDataManager.h:94
&gt; &gt; +                                                                       GError                  ** error);
&gt; 
&gt; Extra space after the **</span >

Good catch.

<span class="quote">&gt; &gt; Tools/ChangeLog:9
&gt; &gt; +        MiniBrowsore to show and handle Website data.
&gt; 
&gt; Is MiniBrowsore a typo or a pun? I can't tell. :D</span >

:-D

<span class="quote">&gt; &gt; Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitWebContext.cpp:736
&gt; &gt; +    test-&gt;wait(1);
&gt; 
&gt; :(</span ></pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>