This is a tracker bug to follow my gdocs backend which can be found here: http://github.com/thiblahute/gvfs/tree/googledocuments

Each comment will correspond to one bug but first here is the review from Desrt:

====== From Desrt Review notes ======
>= style issues =
>gvfs follows glib coding style.  you deviate from it in a lot of ways.
>
>1) functions should look like this:
>
>static int
>g_thingy_frob (GThingy   *thingy,
>               FrobFlag   flag,
>               GError   **error)
>{
>}

Done

>2) indent with two spaces.  if you use tabs for "space compression" (ie: 8             spaces = 1 tab) is up to you, but i personally prefer not.

Done

>3) when using braces, indentation should look like this:                               
>
>int
>function (void)
>{
>  while (condition)
>    {
>      if (condition)
>        {
>          do_stuff();
>          etc();
>        }
>    }
>}
Done
>
>4) you have trailing spaces at the ends of lines (or on empty lines) scatted           throughout the file.  don't do that.
>
>5) you have some blank lines in odd places (like the end of _class_init())                 

Done
>6) try not to exceed 78 characters per line.  wrap like this:
>
>  some_long_function (long_argument_1,
>                      long_argument_2);
>
>if that's not possible, then get more creative.  for example:                             
>
>{
>  const gchar *entry_id = gdata_documents_entry_get_document_id >(GDATA_DOCUMENTS_ENTRY (i->data)); 
>}
>
>could be:
>
>{
>  GDataDocumentsEntry *entry = GDATA_DOCUMENTS_ENTRY (i->data);
>  const gchar *entry_id;
>
>  entry_id = gdata_documents_entry_get_document_id (entry);
>}
>
>the 78-characters thing is really optional.  some prefer 118 characters.

Done

>also, your local variable declarations are just insane.
>
>
>random comments:
>
>- 'i' is an odd variable to use for GList*.  'i' is usually an int.  i use >'node' here.

Done
>
>
>= technical =
>
>in .h you declare g_vfs_backend_gdocs_rebuild_entries_type but in .c it's called
>g_vfs_backend_gdocs_rebuild_entries.  it makes no sense anyway, since who will call it?
>
>the entries hash table never appears to actually be used for anything...... you insert into it from a function that's never called and you never do lookups.

Done
>
>i'd put this in .c since it's part of the implementation:                   >/*Gdata client ID, we should ask for a new one for GVFS*/
>#define CLIENT_ID "ytapi-GNOME-libgdata-444fubtt-0"

Done
>registering dispose functions makes no sense -- they won't be called. put it in finalize instead.  if this would result in a reference loop then talk to me about a solution. :)

Done
>
>you must chain up to the parent ->finalize() function in your finalize.                     
>
>otherwise you leak memory.  do it like this (at the _end_):
>static void
>our_finalize (GObject *object)
>{
>  ...
>  ...
>
>  G_OBJECT_CLASS (g_vfs_backend_gdocs_parent_class)->finalize (object);                    >}
Done

>g_message spew is not appreciated in production code

Done, must check how to get the g_debug printing in the command line
>
>your handling of username/host is a bit strange.  i'd add braces around the else case (ie: "else { if ... }" instead of "else if") to make your intention more clear.  maybe expand the comment to give an example of each case you wish to deal with and the expected result.

Done
>
>strange that you pass 'username' into g_mount_source_ask_password in the else branch where you know that it is NULL.
>
>you present the user with an authentication dialog box in at least 3 cases:
>  - user + passwd needed
>  - passwd needed
>  - passwd error
>
>could probably merge all 3.                                                                 

Done
>
>in the password error case your message doesn't indicate that authentication failed.        

Done
>
>your logic in do_read/do_write with respect to n_bytes is strange.  just by
>looking at the code, it seems possible that job_succeeded() could be called
>without set_size() having been called.  that's not good.  try to split your
>result handling into two simple cases: success and fail.