Re: Proposing libgdata as a new desktop module

[Luis Villa <luis tieguy org>]

I guess a fairly obvious question I should have asked earlier: what
things are there that you want to access via gdata that aren't
systematically available via other protocols (rss, pop, imap, http,
etc.)? That might help clarify a bit what kinds of risks are being run
here. (As I point out later, I use google stuff, like everyone, but
I've never once thought 'man, I wish I could access this via gdata
instead of pop/imap/web browser'.)

On Fri, May 8, 2009 at 2:32 AM, Philip Withnall <philip tecnocode co uk> wrote:
> On Thu, 2009-05-07 at 19:22 -0400, Luis Villa wrote:
>> Lets not fall into the lazy trap of pretending that because something
>> is no-cost that it is effectively the same as being libre-free (or
>> even the same as being pragmatically open.)
>
> I didn't mean to suggest any of Google's services were libre-free; I was
> merely saying that they're free-as-in-beer and a lot more
> well-documented than other protocols. Bad wording on my part.
>
>> Or to put it a different way: feel free to argue for it as a necessary
>> evil; that has been and will continue to be the kind of compromise
>> that GNOME has to make sometimes. But please don't pretend that
>> because it is no-cost that that somehow makes it OK.
>
> I personally think that Google's services are fine; a "necessary evil",
> if you will. They may not be libre-free, but they're in wide use, and
> having access to Google services from the desktop will consequently be
> useful to many people.

Windows is in wide use; is practically free to the vast majority of
computer users; and their APIs are very well documented. Lets just use
that! ;)

I'm only slightly exagerrating; obviously cross-platform gtk, gimp,
etc. are all very good and healthy for us. So we shouldn't ignore
these factors. But the difference is that if you use gimp on windows,
you're one step closer to using a free operating system. That doesn't
appear to be the case here. (If I use IMAP to access gmail, OTOH, I'm
fine, freedom-wise.)

>> Specifically to this point, things like flash and other codecs that we
>> have worked out support for are broadly used by hundreds of thousands
>> (millions?) of people and data providers. gdata... not so much. So
>> work with me here:
>>
>> * is there any reason to believe that there is a trend towards
>> adoption here that we should be aware of? In other words, is this soon
>> going to be well beyond Google, and we should be ready for it? that
>> would be a good argument here; that's basically why we're OK with
>> libswf. Data points that one might muster to prove this would include
>> that open source CMSs (or other open source web-based software) has
>> libraries or plugins that publish gdata endpoints.
>
> If GData is adopted well beyond Google's services, I think it will take
> a while. I've just trawled the web for examples of non-Google services
> which publish GData APIs, and all I could find were these:
> * http://wiki.apache.org/lucene-java/GdataServer
> * http://drupal.org/node/60490
> both of which look dead. There were a few attempts to revive the Drupal
> GData project in 2008; I don't know what became of them.

That is too bad; I'd be curious to know more about why these fizzled
out. (Frankly, though, this doesn't surprise me too much- my sense of
it technically when I looked at it in 2006 was that it was a solution
in search of a problem.)

>> * if it isn't going to spread beyond google (or we have no reason to
>> believe so, at any rate) is there a reason to think that google is
>> special/important enough that we should compromise our values here? Is
>> there a good tactical reason for it? (I'd say that this, roughly, is
>> our relationship to SMB.) (There may be; I'm open to that possibility
>> but don't see it argued for yet.)
>
> As I said above, Google services are very widely used, but I can't speak
> for everyone and say whether that's a good enough reason for adoption.
> Obviously there have been a few people giving unconditional +1s to
> moving libgdata into the desktop set; but there have also been the same
> number raising concerns such as yours.

I'm a google service user as well, so I understand the argument, but I
only give them data if I can get it out in fairly standardized
formats.

>> * alternately, are there ways to make this more general and support
>> alternatives? In other words, should this be a general purpose
>> web-data library (perhaps an atompub library?) in which gdata is but
>> one mode? Should it be integrated with some other, pre-existing
>> network connection or data protocol library?
>
> In its current state, it would take quite some work to make libgdata
> more generalised, if it would work at all. I haven't really looked into
> other web APIs enough to be able to say whether a general approach would
> work sufficiently well.

Nor have I. :) I'd suggest that this would be the best approach, from
a freedom perspective, but obviously technically it might not be
feasible at this time.

I'm not saying there is any clear right or wrong answer overall, but I
really think both you and GNOME should think hard about what behaviors
we're encouraging by endorsing gdata. Hopefully asking these questions
is a useful part of that process :)

Luis