Re: [Cache V2 1/1] grl-net: Use libsoup cache

["Juan A." Suárez Romero <jasuarez igalia com>]

On Fri, 2011-03-11 at 11:27 +0100, Víctor M. Jáquez L. wrote:
> Comments below
> 
> > +  g_object_class_install_property (g_klass,
> > +                                   PROP_IDENTIFIER,
> > +                                   g_param_spec_string ("identifier",
> > +                                                        "GrlNet identifier",
> > +                                                        "Unique identifier for GrlNet",
> > +                                                        NULL,
> > +                                                        G_PARAM_READWRITE |
> > +                                                        G_PARAM_CONSTRUCT_ONLY |
> > +
> >                                                          G_PARAM_STATIC_STRINGS));

> Why should we demand to the API user a cache identifier? I guess we could
> figure out one with out messing the user.


The identifier is used to create a place where to store the cached data.

Right now, the place is ~/.cache/<applicationname>/<identifier>

<applicationname> is easier to get without asking the user
(g_get_prgname())

But identifier is not.

Why we need it? Because as each plugin uses its own GrlNet instance,
which in turns uses its own libsoup instance, Sergio (the guy who worked
in libsoup cache) suggested me to avoid writting in the same directory,
as one instance could overwrite cache from other instances, leading to
unexpected behaviour (sic).


Of course, I could create a random identifier instead asking the user.
But the point is that users generally quit the program, without turning
down the plugins, and thus grl_net_wc_finalize() is almost never
invoked, so the cache becomes there. So if i use a random identifier, i
will fill the cache with lots of files.

I've been thinking how to get an unique identifier that is the same
across the executions, without bothering the user, but I couldn't figure
out.

If you have some suggestion, I would be pleased of using it.



> > +
> > +static void
> > +reply_cb (GObject *source, GAsyncResult *res, gpointer user_data)
> > +{
> > +  GSimpleAsyncResult *result = G_SIMPLE_ASYNC_RESULT (user_data);
> > +  RequestResult *rr = g_simple_async_result_get_op_res_gpointer (result);
> > +
> > +  GInputStream *in = soup_request_send_finish (rr->request, res, NULL);
> > +  rr->length = soup_request_get_content_length (rr->request) + 1;
> > +  if (rr->length == 1) {
> > +    rr->length = BUFFER_SIZE;
> 
> Why 50K as a fallback? 


We need a buffer to store the content when server says nothing about its
length.

I don't know if 50K is a good or bad value. I just checked it because it
seemed a reasonable value.

If you have a different proposal, i'm glad to hear it.


> > +#endif
> > +
> >  /**
> >   * grl_net_wc_new:
> > + * @identifier: an identifier
> 
> Can it be NULL?

It shouldn't be.

Probably I need to add the right check and doc.


> > +#else
> > +  SoupMessage *msg = (SoupMessage *) g_simple_async_result_get_op_res_gpointer (res);
> > +
> > +  if (content != NULL)
> > +    *content = g_strdup ((gchar *) msg->response_body->data);
> 
> mmmhh... I wanted to avoid a mem copy, delegating to the user that option if
> she wants to maintain the data after a new request is done or unref the wc.
> 
> Now that you are forcing the memcopy, we should change all the plugins which
> use this.

Sorry, this is a mistake. Something left doing some tests. I'll fix it.



> We shall verify how the apple trailer plugin goes with this type of cache.
> 


Actually I was checking with this plugin, as it seems it is the only one
that cache is effective (note that libsoup only caches content that
fulfils some requirements).

Using a sniffer, I saw that it works fine: when asking again for the
same content, it is retrieved from the cache instead of asking it to
network.

How this caching affects the performance? To be honest, I didn't notice
a big difference between using cache and not using it. Probably, that is
because I have a pretty decent connection. Probably, using it with other
less good connections (may be a phone connection) makes a big
difference.

But also, the reason to use a cache is not only for performance, but
also to avoid filling the server with unneeded requests, helping to
fulfil some Terms of Service that requires not performing more than X
requests per second.

	J.A.