Re: GNOME Online Accounts extensibility
On Mon, 2011-10-10 at 11:10 -0400, David Zeuthen wrote: > Either way, I don't get why you are so concerned about whether GOA can > be extended. If you buy into the idea that apps will always need to > have a separate panel for non-mainstream accounts then... then the app > can provide the extension point and config-file merging from > ..d-directories. For me, and I'm guessing a few others, we were confused at the scope and the problem that GOA was trying to solve. Not as much "concern" and more "confusion." Thanks for explaining it. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hey, On Mon, Oct 10, 2011 at 11:10 AM, Ken VanDine wrote: > We discussed this with twitter, and they agreed that including the API > key in the packaging instead of in the upstream source was good enough > separation for them. So for example, in the Ubuntu package we include > the "Ubuntu" API key for twitter. And we recommend all distros to do > the same. It would be helpful if you could include the GNOME Foundation, specifically our Executive Director, in these discussions as one of the questions we are currently dealing with is exactly how to manage API keys. As I've said, it's something that we're blocking on in GOA... in fact, it's why GOA only supports Google because Google still works without API keys. (FWIW, my view is that in order for GNOME to keep a straight face, free software-wise, and for things like jhbuild to work, we need GOA's configure.ac file to include the API keys for each provider and the Foundation will need to manage the keys. Whether each downstream patches in its own keys (for one reason or another) and what the Foundation's advice in this matter is (do we encourage downstream's to use the Foundation API keys?) is a separate question.) Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
We discussed this with twitter, and they agreed that including the API key in the packaging instead of in the upstream source was good enough separation for them. So for example, in the Ubuntu package we include the "Ubuntu" API key for twitter. And we recommend all distros to do the same. --Ken On Mon, 2011-10-10 at 11:39 +0200, Rodrigo Moya wrote: > On jue, 2011-10-06 at 14:30 -0400, Ken VanDine wrote: > > Sorry, not trying to sound harsh here but I couldn't find a better way > > to say this. > > > > Basically you are saying that GOA isn't really an open technology to > > help consolidate user's online accounts, it is only to help consolidate > > accounts for blessed GNOME apps? This doesn't really help users in the > > big picture, but I guess the design team makes those decisions. > > > GOA already has support for Twitter and Facebook accounts, they are just > disabled in the build by default because of the legal issues David > mentions. > > In fact, I asked about enabling them by default recently, and David > explained the distributing-the-keys problem, which needs to be solved. > So, there's nothing to do with designers, it's just a legal issue. > > Out of curiosity, what keys does gwibber use? does it distribute them? > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Sat, Oct 8, 2011 at 12:11 PM, Ted Gould wrote: > So to be clear, you see GOA's configurability to be in setting up new > account groups, but new protocols. So I could add "Corp. Account" but > if my corp. uses a protocol that GNOME OS doesn't use otherwise, I > couldn't add this. Trying to understand what configurability you expect > in the future. The way to look at GOA is that it's just one provider of accounts. As I said, GOA is by no means a substitute for having a separate way to configure an app for accounts - if it was, then GOA would be a choke point in this way: it just makes no sense to add protocol-support in both the app and in GOA to make things work - you end up with ugly dependencies between the app, libgoa and the running goa-daemon(8) instance. Which makes it really hard to get anything done. So just from a technical point of view the "I want to use GOA to configure everything" is a non-starter, I think. You should think of GOA as something that the app can optionally depend on to make using 'suites' of services (e.g. Google, Yahoo) just work in the sense that you logon once and then the auth token is used for all services, e.g. mail, chat, calendar etc. And no-one says that only GNOME apps (such as Evolution) can use this - no one is preventing e.g. Thunderbird from consuming the same kind of data. The other thing is that we do not want the UX in the Online Accounts preference pane to look like this http://people.freedesktop.org/~david/lots-of-account-types-that-i-don't-know-about.png Not that there's anything per-se wrong with that kind of UI in Empathy (the same way there's nothing wrong with all the Chrome you find in e.g. Gimp) - we just don't to expose the user to it if we can avoid it. The idea of Online Accounts has been from the start that this is something the user sees in either the OS installer or as part of some "Initial Setup" experience, see e.g. https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup So you ask about extending GOA and I've already explained a bit about that upthread. It's not that I'm 100% opposed to it, heck as I said we used to read config files, and double-plus-heck, the code is already using gio extension points, see http://developer.gnome.org/goa/unstable/GoaProvider.html#GOA-PROVIDER-EXTENSION-POINT-NAME:CAPS http://developer.gnome.org/goa/unstable/GoaProvider.html#goa-provider-get-for-provider-type we just don't read any GIO modules just yet. As I said upthread, the only reason this is so is basically because a) providing a stable API for extensions is expensive; and b) providing a stable config file format is also expensive; and c) it's too easy to abuse to create substandard UX in the Online Accounts preference pane. Well, where to go from here? a) and b) will clearly be non-issues around 3.4 or 3.6 as things stabilize [1]. It's more c) I'm concerned about. To resolve this we need to work with the designers to make sure that the UX can scale in the presence of many different account types. Either way, I don't get why you are so concerned about whether GOA can be extended. If you buy into the idea that apps will always need to have a separate panel for non-mainstream accounts then... then the app can provide the extension point and config-file merging from .d-directories. David [1] : note that we said the same about GVfs and GVfs backends are still private GNOME API 3 years later. Which turned out to not really be a problem even though everyone whined about it about the fact that there is no stable GVfs API. But it works really well for GVfs, heck we got all the interesting parts _in the GVfs tree_ instead of them being random 3rd party things seeing less testing. It's similar to how the Linux kernel works. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On Mon, 2011-10-10 at 12:36 +0100, Martyn Russell wrote: > On 10/10/11 10:39, Rodrigo Moya wrote: > > On jue, 2011-10-06 at 14:30 -0400, Ken VanDine wrote: > >> Sorry, not trying to sound harsh here but I couldn't find a better way > >> to say this. > >> > >> Basically you are saying that GOA isn't really an open technology to > >> help consolidate user's online accounts, it is only to help consolidate > >> accounts for blessed GNOME apps? This doesn't really help users in the > >> big picture, but I guess the design team makes those decisions. > >> > > GOA already has support for Twitter and Facebook accounts, they are just > > disabled in the build by default because of the legal issues David > > mentions. > > > > In fact, I asked about enabling them by default recently, and David > > explained the distributing-the-keys problem, which needs to be solved. > > So, there's nothing to do with designers, it's just a legal issue. > > > > Out of curiosity, what keys does gwibber use? does it distribute them? > > Disclaimer: I am not savy to all the details here. > > With Ubuntu's approach in their last distribution to FaceBook/Twitter > (i.e. asking the user to accept the terms themselves during set up), > isn't that accepting the "key" here? Or is this some sort of SDK key? You need a per-app API key to be able to use the APIs. The terms of service for apps generally require this key to be "hidden" which (appart from being silly, the code need to be able to read the key, so how hidden can it be?) means that this is not possible for an open source application to fullfill the service agreement. Additionally, many web services have terms of services for apps that are pretty bad. Twitter in particular recently upgraded theirs to be very harsh on 3rd party clients: http://arstechnica.com/software/news/2011/03/twitter-tells-third-party-devs-to-stop-making-twitter-client-apps.ars For instance, look at: https://dev.twitter.com/terms/display-guidelines If you don't follow that exactly they can retract your key and break your app... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On 10/10/11 10:39, Rodrigo Moya wrote: On jue, 2011-10-06 at 14:30 -0400, Ken VanDine wrote: Sorry, not trying to sound harsh here but I couldn't find a better way to say this. Basically you are saying that GOA isn't really an open technology to help consolidate user's online accounts, it is only to help consolidate accounts for blessed GNOME apps? This doesn't really help users in the big picture, but I guess the design team makes those decisions. GOA already has support for Twitter and Facebook accounts, they are just disabled in the build by default because of the legal issues David mentions. In fact, I asked about enabling them by default recently, and David explained the distributing-the-keys problem, which needs to be solved. So, there's nothing to do with designers, it's just a legal issue. Out of curiosity, what keys does gwibber use? does it distribute them? Disclaimer: I am not savy to all the details here. With Ubuntu's approach in their last distribution to FaceBook/Twitter (i.e. asking the user to accept the terms themselves during set up), isn't that accepting the "key" here? Or is this some sort of SDK key? -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On 07/10/11 15:21, Matthias Clasen wrote: On Fri, Oct 7, 2011 at 9:05 AM, Ted Gould wrote: IMHO, the problem with GOA is its lack of extensibility. So adding something like a corporate account type is difficult if not impossible. For instance, if was foo corp, and we had internal mail, jabber and status.net services -- I'd like to provide one way to provide this configuration and have one place for users to set up their accounts. Care to elaborate ? Why would it be difficult or impossible ? Extensibility was very much on the agenda when GOA was designed. But GOA is not a 'generic account setup' dialog to allow all the worlds apps to drop their own account setup dialogs. If that is what you are looking for, you will be disappointed. It is the central place to set up accounts that are integrated in GNOME apps. If third-party apps can use the same account information, that is great. But we don't want to crowd the provider list with providers that are not integrated at least in some GNOME apps. And we don't want to add switches for services that are not covered by GNOME apps. I think it makes sense for the dialog to be a broker on behalf of _ALL_ apps using that information and the user who has it. Of course it doesn't make sense to display account set up information for service Foo if no application can make use of it. So I would suggest the need to register "clients" to make sure configurations are listed *when* it makes sense. I must admit, when I saw the "Online Accounts" entry in the menu, I was excited at the prospect that finally the Telepathy mission-control or accounts dialog had been integrated into GNOME properly. From other comments in this thread, I also realise that it's not just about IM communications but also clouds as some are expecting. -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On jue, 2011-10-06 at 14:30 -0400, Ken VanDine wrote: > Sorry, not trying to sound harsh here but I couldn't find a better way > to say this. > > Basically you are saying that GOA isn't really an open technology to > help consolidate user's online accounts, it is only to help consolidate > accounts for blessed GNOME apps? This doesn't really help users in the > big picture, but I guess the design team makes those decisions. > GOA already has support for Twitter and Facebook accounts, they are just disabled in the build by default because of the legal issues David mentions. In fact, I asked about enabling them by default recently, and David explained the distributing-the-keys problem, which needs to be solved. So, there's nothing to do with designers, it's just a legal issue. Out of curiosity, what keys does gwibber use? does it distribute them? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On Fri, 2011-10-07 at 10:49 -0400, David Zeuthen wrote: > If you examine the GOA project and its git log, You can rest assured that I haven't read the git log, I did look at the last release though :-) > combined with the idea of supporting generic IMAP/SMTP/XMPP/Caldav > configurations, see > > https://bugzilla.gnome.org/show_bug.cgi?id=661117 > > that Patryk filed on my request... then... then GOA can be pretty nice > from a corporate point of view. Because with that the you'd just drop > a single config file in /etc/goa-1/config.d/mail.conf specifying the > $u...@company.com for email, something else for XMPP and so on. So to be clear, you see GOA's configurability to be in setting up new account groups, but new protocols. So I could add "Corp. Account" but if my corp. uses a protocol that GNOME OS doesn't use otherwise, I couldn't add this. Trying to understand what configurability you expect in the future. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On Fri, 2011-10-07 at 10:21 -0400, Matthias Clasen wrote: > And we don't want to add switches for services that are not covered by > GNOME apps. Could you elaborate on the term "GNOME apps" in this context please? For instance, if Inkscape wanted to have account settings for the recently published Deviant Art APIs would that be allowed? Or is it encouraged that when Inkscape runs on GNOME OS it should provide it's own account setup dialog for those APIs? --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On Fri, 2011-10-07 at 10:21 -0400, Matthias Clasen wrote: > But GOA is not a 'generic account setup' dialog to allow all the > worlds apps to drop their own account setup dialogs. If that is what > you are looking for, you will be disappointed. It is the central place > to set up accounts that are integrated in GNOME apps. If third-party > apps can use the same account information, that is great. But we don't > want to crowd the provider list with providers that are not integrated > at least in some GNOME apps. > And we don't want to add switches for services that are not covered by > GNOME apps. What about GNOME apps themselves adding GOA extensions for services they support? I still think GOA would be a good fit for the initial setup of groupware accounts that Evolution knows how to handle. I could see Evolution adding extension modules for Exchange, GroupWise, Zimbra, Kolab, etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Fri, Oct 7, 2011 at 9:05 AM, Ted Gould wrote: > IMHO, the problem with GOA is its lack of extensibility. So adding > something like a corporate account type is difficult if not impossible. > For instance, if was foo corp, and we had internal mail, jabber and > status.net services -- I'd like to provide one way to provide this > configuration and have one place for users to set up their accounts. I > think handling this use case could provide some guidance for where GOA > could go in making users who are corporate environments lives easier. If you examine the GOA project and its git log, we actually did use to read config files from /etc/goa-1/config.f and ~/.config/goa-1.0/config.d (or something similar to that). But I ripped this out as I didn't want to commit to a config file format for 3.2. Why? Because it's never smart to paint yourself into a corner for new stuff. But no-one says we can't do it for 3.4 or 3.6 or whatever. In particular, having 1. a stable config file format; and 2. .d directories in /etc and $HOME; and 3. something $USER expansion in config files combined with the idea of supporting generic IMAP/SMTP/XMPP/Caldav configurations, see https://bugzilla.gnome.org/show_bug.cgi?id=661117 that Patryk filed on my request... then... then GOA can be pretty nice from a corporate point of view. Because with that the you'd just drop a single config file in /etc/goa-1/config.d/mail.conf specifying the $u...@company.com for email, something else for XMPP and so on. But please note: all this has absolutely nothing to do with Ken's rant. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On Fri, Oct 7, 2011 at 9:05 AM, Ted Gould wrote: > > IMHO, the problem with GOA is its lack of extensibility. So adding > something like a corporate account type is difficult if not impossible. > For instance, if was foo corp, and we had internal mail, jabber and > status.net services -- I'd like to provide one way to provide this > configuration and have one place for users to set up their accounts. Care to elaborate ? Why would it be difficult or impossible ? Extensibility was very much on the agenda when GOA was designed. But GOA is not a 'generic account setup' dialog to allow all the worlds apps to drop their own account setup dialogs. If that is what you are looking for, you will be disappointed. It is the central place to set up accounts that are integrated in GNOME apps. If third-party apps can use the same account information, that is great. But we don't want to crowd the provider list with providers that are not integrated at least in some GNOME apps. And we don't want to add switches for services that are not covered by GNOME apps. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On Thu, 2011-10-06 at 14:49 -0400, David Zeuthen wrote: > On Thu, Oct 6, 2011 at 2:30 PM, Ken VanDine wrote: > > Sorry, not trying to sound harsh here but I couldn't find a better way > > to say this. > > > > Basically you are saying that GOA isn't really an open technology to > > help consolidate user's online accounts, it is only to help consolidate > > accounts for blessed GNOME apps? This doesn't really help users in the > > big picture, but I guess the design team makes those decisions. > > > > Does this mean third party developers shouldn't try to leverage GNOME as > > a platform anymore? Maybe that is a topic for another thread, as much > > as I love GNOME, it is becoming harder and harder to develop for. I > > miss the days when GNOME was a platform, I hope there is a way we can > > change that and turn it into a platform again! > > I think your mail is actually pretty offensive and also > misrepresenting GNOME. I will not reply to it. Huh, I think you pretty much answered Ken's question indirectly. :-) IMHO, the problem with GOA is its lack of extensibility. So adding something like a corporate account type is difficult if not impossible. For instance, if was foo corp, and we had internal mail, jabber and status.net services -- I'd like to provide one way to provide this configuration and have one place for users to set up their accounts. I think handling this use case could provide some guidance for where GOA could go in making users who are corporate environments lives easier. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Thu, Oct 6, 2011 at 3:05 PM, Patryk Zawadzki wrote: > On Thu, Oct 6, 2011 at 7:40 PM, David Zeuthen wrote: >> I. Adding support for a provider P, currently means making code-changes to >> all of the GNOME apps using its services.. because most of the time >> standard >> standardized protocols are not in use. For the few cases where it >> uses a standard >> protocol (such as XMPP and IMAP/SMTP) we could support pluggable >> providers. >> >> For example, we could, presumably, read "plug-in" files from some >> directory >> so we could list 200 different XMPP chat services or 200 different >> IMAP servers. >> That that no-one ever heard about. But would we want the user to >> see this? The >> answer is: not in GOA. > > Can't we just have an option that says "Other Jabber/XMPP provider" > and allows me to enter my JID, the server name, password, port etc.? > It would cover most of people's needs even if they need to ask the > provider for details (that they have to provide anyway). Most > importantly it would mean not using two configuration windows, one of > which not showing anything other than Google and the other saying that > some accounts "could not be configured here". The current state of > affairs leads to confusion (I had to explain that to a live person, I > failed because I did not have any sensible arguments). > > Same could probably be done for IMAP/POP3/SMTP. And also for calendar since there's a couple of standardized protocols. FWIW, I don't think it's a bad idea and I actually did something like this early on, see http://people.freedesktop.org/~david/gen-mail-1.png http://people.freedesktop.org/~david/gen-mail-2.png http://people.freedesktop.org/~david/gen-mail-3.png http://people.freedesktop.org/~david/gen-mail-4.png but IIRC the designers had some objections and I ended up running out of time. I'll try to grab the designers again. Would you mind filing a bug about it? Thanks! David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On Thu, Oct 6, 2011 at 7:40 PM, David Zeuthen wrote: > I. Adding support for a provider P, currently means making code-changes to > all of the GNOME apps using its services.. because most of the time > standard > standardized protocols are not in use. For the few cases where it > uses a standard > protocol (such as XMPP and IMAP/SMTP) we could support pluggable providers. > > For example, we could, presumably, read "plug-in" files from some directory > so we could list 200 different XMPP chat services or 200 different > IMAP servers. > That that no-one ever heard about. But would we want the user to > see this? The > answer is: not in GOA. Can't we just have an option that says "Other Jabber/XMPP provider" and allows me to enter my JID, the server name, password, port etc.? It would cover most of people's needs even if they need to ask the provider for details (that they have to provide anyway). Most importantly it would mean not using two configuration windows, one of which not showing anything other than Google and the other saying that some accounts "could not be configured here". The current state of affairs leads to confusion (I had to explain that to a live person, I failed because I did not have any sensible arguments). Same could probably be done for IMAP/POP3/SMTP. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Thu, Oct 6, 2011 at 2:30 PM, Ken VanDine wrote: > Sorry, not trying to sound harsh here but I couldn't find a better way > to say this. > > Basically you are saying that GOA isn't really an open technology to > help consolidate user's online accounts, it is only to help consolidate > accounts for blessed GNOME apps? This doesn't really help users in the > big picture, but I guess the design team makes those decisions. > > Does this mean third party developers shouldn't try to leverage GNOME as > a platform anymore? Maybe that is a topic for another thread, as much > as I love GNOME, it is becoming harder and harder to develop for. I > miss the days when GNOME was a platform, I hope there is a way we can > change that and turn it into a platform again! I think your mail is actually pretty offensive and also misrepresenting GNOME. I will not reply to it. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Sorry, not trying to sound harsh here but I couldn't find a better way to say this. Basically you are saying that GOA isn't really an open technology to help consolidate user's online accounts, it is only to help consolidate accounts for blessed GNOME apps? This doesn't really help users in the big picture, but I guess the design team makes those decisions. Does this mean third party developers shouldn't try to leverage GNOME as a platform anymore? Maybe that is a topic for another thread, as much as I love GNOME, it is becoming harder and harder to develop for. I miss the days when GNOME was a platform, I hope there is a way we can change that and turn it into a platform again! --Ken On Thu, 2011-10-06 at 13:40 -0400, David Zeuthen wrote: > Hi, > > On Thu, Oct 6, 2011 at 12:52 PM, Ken VanDine wrote: > > I really want to get rid of gwibber-accounts for configuring accounts in > > Gwibber. It makes sense to use GOA for this, > > I don't think it necessarily does, no. See below. > > > however gwibber supports > > quite a few social networks as well as supporting third party service > > plugins. So anyone can add support for a new social network without > > changing gwibber. So to transition to using GOA, we would need to > > include support for all the social networks Gwibber supports out of the > > box, and provide a way for third party developers to include the > > necessary provider for GOA. > > > > This really won't be manageable if all the providers need to be merged > > upstream with GOA and included in a release. > > > > Thoughts? > > Well, until we've figured out a story in GNOME for how "social > networks" are integrated, it just doesn't make sense to add this to > GOA. The more general observation (of which the above is a > specialization of) is that we do not add support for providers P (e.g. > Google, Facebook) or services S (e.g. Documents, Mail, Chat, Calendar, > Contacts) until > > 1. we know how it's going to be used in a GNOME release; and > > 2. there is something in the GNOME release using it. > > Basically: you need to work with the GNOME Designers on figuring out > how "social networks" fit in. > > For GNOME 3.2 we have the following users: > > - Empathy / GNOME Shell (Chat) > - Evolution (Mail, Calendar) > - GNOME Contacts (Contacts) > - GNOME Documents (Documents) > > and we still only support Google as a provider. Why? Because Google is > right now the only provider where > > a) we can use anonymous API keys; and > > b) we have support for Google in the above-mentioned apps > > The other problem is how to handle API keys. As I have mentioned > before on this list and elsewhere, a couple of months ago I sent a > long mail with legal questions to the GNOME Foundation and I'm still > waiting on a response. Basically, we want to be able to legally ship > API keys along with GOA. So it boils down to this: even if we had all > the protocol support for, say, Facebook in, say, GNOME Contacts > (through libfolks) and Empathy (through Telepathy) we would not be > able to turn it on because of unresolved API key and legal questions. > > > Are there plans for making service providers in GOA pluggable? > > Not at this point, no, and probably not in the future either. Why? Two reasons > > I. Adding support for a provider P, currently means making code-changes to > all of the GNOME apps using its services.. because most of the time > standard > standardized protocols are not in use. For the few cases where it > uses a standard > protocol (such as XMPP and IMAP/SMTP) we could support pluggable > providers. > > For example, we could, presumably, read "plug-in" files from some > directory > so we could list 200 different XMPP chat services or 200 different > IMAP servers. > That that no-one ever heard about. But would we want the user to > see this? The > answer is: not in GOA. But see II. below > > II. To avoid user confusion we only want the major online services in GOA. > Support for more specialized protocols/services should happen in each > separate app - that's why, for example, that Empathy still has a > preferences > menu so you can add support for e.g. ICQ, Zephyr and other fringe chat > services and protocols. And that's also why you still have support in > Evolution for manually adding IMAP/SMTP servers. > > I will try and add some of these guidelines (or "rules" if you want) > to the GOA documentation, see > > http://developer.gnome.org/goa/unstable/ > > for what it looks like right now. > > David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Thu, Oct 6, 2011 at 2:10 PM, Steve Frécinaux wrote: > On 10/06/2011 07:40 PM, David Zeuthen wrote: >> >> II. To avoid user confusion we only want the major online services in GOA. >> Support for more specialized protocols/services should happen in each >> separate app - that's why, for example, that Empathy still has a >> preferences >> menu so you can add support for e.g. ICQ, Zephyr and other fringe chat >> services and protocols. And that's also why you still have support in >> Evolution for manually adding IMAP/SMTP servers. > > What about free (or not free) services you can install on your own box but > would still provide services for many different programs? > > I'm thinking about owncloud, for instance, which provides document storage, > calendar, bookmarks, etc. > > Sure this is not a "well known" service, but yet I think many would like to > be able to add such services, due to our natural love of freedom and not > promoting big companies without alternatives. I agree it would be nice if the free software community could come up with a credible alternative to Google, Yahoo or Microsoft's Live to name just three. And I definitely think if such a credible alternative were to surface we should definitely support it in GNOME along the same lines of the non-free ones, perhaps even giving it special treatment because its free. Whether OwnCloud specifically is this project remains to be seen - but see https://bugzilla.gnome.org/show_bug.cgi?id=660573 for the request to add OwnCloud support to GOA (the reason I haven't replied to that bug yet is that I want to get the guidelines I gave upthread into the goa docs). David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On 10/06/2011 07:40 PM, David Zeuthen wrote: II. To avoid user confusion we only want the major online services in GOA. Support for more specialized protocols/services should happen in each separate app - that's why, for example, that Empathy still has a preferences menu so you can add support for e.g. ICQ, Zephyr and other fringe chat services and protocols. And that's also why you still have support in Evolution for manually adding IMAP/SMTP servers. What about free (or not free) services you can install on your own box but would still provide services for many different programs? I'm thinking about owncloud, for instance, which provides document storage, calendar, bookmarks, etc. Sure this is not a "well known" service, but yet I think many would like to be able to add such services, due to our natural love of freedom and not promoting big companies without alternatives. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Thu, Oct 6, 2011 at 12:52 PM, Ken VanDine wrote: > I really want to get rid of gwibber-accounts for configuring accounts in > Gwibber. It makes sense to use GOA for this, I don't think it necessarily does, no. See below. > however gwibber supports > quite a few social networks as well as supporting third party service > plugins. So anyone can add support for a new social network without > changing gwibber. So to transition to using GOA, we would need to > include support for all the social networks Gwibber supports out of the > box, and provide a way for third party developers to include the > necessary provider for GOA. > > This really won't be manageable if all the providers need to be merged > upstream with GOA and included in a release. > > Thoughts? Well, until we've figured out a story in GNOME for how "social networks" are integrated, it just doesn't make sense to add this to GOA. The more general observation (of which the above is a specialization of) is that we do not add support for providers P (e.g. Google, Facebook) or services S (e.g. Documents, Mail, Chat, Calendar, Contacts) until 1. we know how it's going to be used in a GNOME release; and 2. there is something in the GNOME release using it. Basically: you need to work with the GNOME Designers on figuring out how "social networks" fit in. For GNOME 3.2 we have the following users: - Empathy / GNOME Shell (Chat) - Evolution (Mail, Calendar) - GNOME Contacts (Contacts) - GNOME Documents (Documents) and we still only support Google as a provider. Why? Because Google is right now the only provider where a) we can use anonymous API keys; and b) we have support for Google in the above-mentioned apps The other problem is how to handle API keys. As I have mentioned before on this list and elsewhere, a couple of months ago I sent a long mail with legal questions to the GNOME Foundation and I'm still waiting on a response. Basically, we want to be able to legally ship API keys along with GOA. So it boils down to this: even if we had all the protocol support for, say, Facebook in, say, GNOME Contacts (through libfolks) and Empathy (through Telepathy) we would not be able to turn it on because of unresolved API key and legal questions. > Are there plans for making service providers in GOA pluggable? Not at this point, no, and probably not in the future either. Why? Two reasons I. Adding support for a provider P, currently means making code-changes to all of the GNOME apps using its services.. because most of the time standard standardized protocols are not in use. For the few cases where it uses a standard protocol (such as XMPP and IMAP/SMTP) we could support pluggable providers. For example, we could, presumably, read "plug-in" files from some directory so we could list 200 different XMPP chat services or 200 different IMAP servers. That that no-one ever heard about. But would we want the user to see this? The answer is: not in GOA. But see II. below II. To avoid user confusion we only want the major online services in GOA. Support for more specialized protocols/services should happen in each separate app - that's why, for example, that Empathy still has a preferences menu so you can add support for e.g. ICQ, Zephyr and other fringe chat services and protocols. And that's also why you still have support in Evolution for manually adding IMAP/SMTP servers. I will try and add some of these guidelines (or "rules" if you want) to the GOA documentation, see http://developer.gnome.org/goa/unstable/ for what it looks like right now. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
