Re: Online Accounts panel for 3.2
Hi David, On 04/19/2011 05:42 PM, David Zeuthen wrote: I did briefly look at http://gitorious.org/accounts-sso/accounts-glib but quickly got lost as that appears to be just the client-side GLib glue. And some of the other stuff looked pretty specific to Meego. No, it isn't just a glue thing :-) It's the full thing, its only dependencies (beside GLib) are SQLite and D-Bus. Can you give a short overview of exactly what components that you've written that GNOME would use (including their dependencies and whether it's a per-session daemon, per-system daemon or shared library), what GNOME would need to write itself and how it would fit together with the UX that I've described? I mean, obviously accounts-glib would be an external dep and obviously we'd write our own GNOME Control Center panel ... but what else? I'm asking mostly to figure out what additional dependencies this would add to GNOME if we were to use it! Sure. So, let's start with what we have: Account library (libaccounts-glib) Dependencies: GLib, SQLite, D-Bus Provided functionality: - enumeration and parsing of provider, service and service-type XML files - reading/writing of accounts settings (with fallback to settings hardcoded in the service XML files) - change notification mechanism SSO library (libsignon-glib) Dependencies: GLib, D-Bus Functional dependencies: SSO daemon (the D-Bus service) Provided functionality: - thin wrapper around the signon D-Bus API; see the SSO daemon description SSO daemon (signon) Dependencies: Qt, libcryptsetup Provided functionality: - Secure storage of user credentials - Provides authentication tokens to applications - SASL plugin, OAuth and plain password plugins are available; more can/should be written I'm sure that some people had a repulsive reaction when reading the word Qt. :-) But it's not so bad as it seems: the daemon does not generate any UI (and is actually built without the QtGui module), it requests UI interactions via D-Bus and therefore the UI itself could be written using whatever tooltik. If the very fact that the daemon itself is written in Qt is unacceptable, it can also be rewritten in another language/toolkik -- but I personally wouldn't be interested in this exercise (though I would still be available for helping the development team). Both libaccounts-qt and libsignon-qt variants exist for these components, and even if this is not strictly interesting for Gnome developers, it's one more thing to consider: it could help in sharing the same user data with the KDE desktop and with Qt applications. Now, the list of what is missing: - Control panel applet - Account UI plugins (unless the setup flow is hardcoded in the control panel applet); according to how the CPA is designed, these could be just some XML/json files describing the UIs - SSO UI: a daemon exposing a simple D-Bus API; it will take care of showing notifications/login dialogs to the user on failed authentications (or when the secure storage is unavailable) Also note that the Accounts SSO frameworks are orthogonal to each other, and you can use one without the other. Hope this helped, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On 04/20/2011 10:08 AM, Alberto Mardegan wrote: SSO daemon (signon) Dependencies: Qt, libcryptsetup Provided functionality: - Secure storage of user credentials - Provides authentication tokens to applications - SASL plugin, OAuth and plain password plugins are available; more can/should be written Forgot to mention two very important features (at least when it comes to embedded or corporate environment): - restrictions on authentication methods: the creator of the account can specify what authentication methods can be used to authenticate. For instance, you might want to prevent the plain password method to be used (so that the password will not be exposed to the applications). - ACL: the creator of the account can specify what applications can use the credentials (this is done using the MeeGo security framework [0]). The DB structure in signond allows more fine-grained control, such as specifying different restrictions on allowed methods depending on the requesting application, but this is not exposed in the API. Ciao, Alberto [0] https://meego.gitorious.org/meego-platform-security -- http://blog.mardy.it -- geek in un lingua international! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On 04/19/11 16:12, Alberto Mardegan wrote: On 04/19/2011 04:08 PM, David Zeuthen wrote: Hey, One of the things I'm looking at doing for 3.2 is the Web Accounts panel: http://live.gnome.org/ThreePointOne/Features/Sharing See the Current status section in that page. We already have all of this (and more) in MeeGo, and I'm willing to support any efforts in bringing this to Gnome. I've looked at the libaccounts + sso stuff work you've done, and it's certainly interesting and had a lot of thought behind it. Kudos. Side note: I think part of integrating it with the GNOME desktop would involve integrating it with gnome-keyring for secret storage. But on to the main point: It seems to me the architecture of Meego SSO is very security focused. In particular it uses pass through authentication to keep credentials away from the applications that are using them. Essentially it doesn't even trust the applications that its authenticating. This is wonderful security from a theoretical point of view. However I think that this could get in the way of broader adoption. In order to succeed, you would need patch every GNOME application and library to not do its own authentication (DIGEST, NTLM, OAuth, CRAM, GSSAPI, and so on...) but have them call out to the daemon. This is not impossible but requires a large amount of commitment and time by someone (probably you). It's not something that will likely happen by the various projects on their own. If the goal is to have this work with the entire desktop (not just GNOME) then certain applications (think Mozilla) would be very challenging to refactor in this way. The amount of work that this involves brings me to question the practical value of hiding the secrets from the applications. Here are some thoughts: * As security people we often tend to think of the credentials as the holy grail. In our minds it is the thing to be protected at all costs. However for many use cases this is not true. The user's data is often really the item of utmost importance. An application must be trusted if it has access to the user's online account and by extension their data. It doesn't matter whether it has credentials or not. * Many auth protocols have no way to hide the secret from the client application and instead rely on wire encryption to provide security. OAuth 2.0 (as used on Facebook) has converged on bearer tokens. Anything that has the token can authenticate. This means there's no way to hide the secret from the application. The same is true for the plethora of applications using using LOGIN, PLAIN or BASIC authentication over TLS. * Pass through authentication adds way more moving parts to any app implementing authentication or anyone wishing to implement a new authentication method. I myself am torn here between the theoretical security benefits of being anal about credentials, and the practical benefits of letting applications do their own authentication. One thing I'm pretty sure about: using pass through authentication to effect SSO, and keeping the credentials away from applications, will make adoption of the Meego SSO bits in GNOME a challenge. Of course, these obstacles are not insurmountable if you put enough lots of time and effort in. Cheers, Stef ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 17:06 +0200, Patrick Ohly wrote: On Di, 2011-04-19 at 16:34 +0200, Rodrigo Moya wrote: On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote: Regarding couchdb: how complete is its data model? When it first showed up, SyncEvolution had some problems with it because REV wasn't supported, if memory serves me right. IIRC, that was a bug you filed for evolution-couchdb, which didn't include the REV field, which I fixed some months ago. Does it support arbitrary vCard extensions? evolution-couchdb supports whatever Evolution supports, which has several vCard extensions (X-EVOLUTION-* fields for instance), so yes, it does As for couchdb, it's a schema-free database, so it can support whatever we want it to ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 09:43 -0700, Travis Reitter wrote: On Tue, 2011-04-19 at 13:48 +0200, Rodrigo Moya wrote: On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: As Frederic pointed out, we shouldn't be brainstorming on the 3.2 feature pages, so I thought I'd fill in some details/thoughts on the Contacts [1] idea here. The page suggests libfolks and/or libsocialweb for the implementation. The good news is that Folks 0.5.0 (released last week) added support for libsocialweb, so using Folks gets you both. In the process, Alban Crequy also added Contacts support for a few libsocialweb services in libsocialweb itself (Flickr, Twitter, Last.FM) and upstreamed Marco Barisione's Facebook support. The remaining lsw services (such as Vimeo and YouTube) don't have Contacts support yet, but it could certainly be added. this makes a lot of sense, but we really need a way to send messages to facebook/twitter contacts, or do other operations on the other services (see photos from flickr, listen to music in last.fm, etc). So, are there any plans for a twitter/facebook client app? None that I know of. We already support Facebook's XMPP chat through Telepathy but not its email-like messaging system. Can third party clients use that anyhow? I thought that was completely walled off. I'm not terribly familiar with the details of Twitter - it just supports 140-char global posts and private messages between users, right? yes Handling sending these messages is probably best implemented as protocol handlers for Evolution, since they don't quite fit in with Telepathy's model and I think libsocialweb avoids communication to keep its scope narrower. it doesn't quite fit into Evolution neither, afaics. The private messages between users do, right, but not the global posts. Showing that as email messages might work, not sure, but it doesn't sound too right to me. Ditto for IM, so that's why I think a separate app, well integrated into the shell, might be the way to go There's also the question of whether we should be encouraging people to use Facebook's or Twitter's private message systems when email is quite a bit more open/easily-accessible/user-controlled. I was talking about public posts, not private messages ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Control Center items (Was Re: Online Accounts panel for 3.2)
Le mardi 19 avril 2011 à 11:32 -0400, David Zeuthen a écrit : Hi, On Tue, Apr 19, 2011 at 11:24 AM, Frederic Peters fpet...@gnome.org wrote: I am also of the opinion we want a single panel; but I think the design of the online accounts panel should allow the accounts that are currently in the messaging and voip accounts panel I agree. ; nothing really new here, I had that old mockup in mind: http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/control%20center/web-services/web-services-2.png Yeah, I looked at this too.. and it's somewhat what I had in mind - the only difference is that I think we need to support multiple instances (e.g. multiple Google accounts - I personally have both a gmail.com account and also a google-hosted fubar.dk account). While this might be a 5% thing (I think it's slightly higher actually), enough of us hackers use such a feature so not supporting it means a lot of people won't be eating the dogfood. I think the main question here is: should this new capplet be a full replacement/superset of the existing empathy-accounts? According to https://live.gnome.org/Design/SystemSettings/Profile#Discussion that's still an open question but in your mail you mention that you want to support unbranded services. For example should this new capplet support the following use cases: - Configure an IRC account to connect to freenode. - Configure an IRC account to connect to an user specific IRC network (like the IRC server of his company). - Configure a SIP account to connect to well known SIP provider (such as voipbuster for example). - Configure a SIP account to connect to the SIP server of his company. - Configure his @jabber.org XMPP account. - Enable/Disable his Salut account; 'People Nearby' in Empathy. - Configure a Groupwise, Gadugadu, Zephyr (add any extra not so common protocol supported by libpurple here) account. Be aware than configuring unbranded services often means we have to expose lot of technical options. Just take a look on the advanced section of the XMPP or SIP widget in empathy-accounts. ~ I'm also wondering what kind of user settings we want to expose here. According to https://live.gnome.org/Design/SystemSettings/Profile#Scope this dialog should allow user to change his display name and user image. In the IM world I guess that means the user alias and avatar. Do we want to include his personal info (exposed on the service) as well: address, phone number, birthday date, etc. If we do, that could be a full replacement of Empathy's Personal Information dialog. Is that what we want? I'm all in favour of having a more desktop integrated IM accounts management, but we have to think carefully about the user experience we want to offer before jumping to the technical implementation details. Designers have a key role to play here. G. -- Guillaume Desmottes gdesm...@gnome.org Jabber cass...@jabber.belnet.be GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Mi, 2011-04-20 at 10:58 +0200, Rodrigo Moya wrote: On Tue, 2011-04-19 at 17:06 +0200, Patrick Ohly wrote: On Di, 2011-04-19 at 16:34 +0200, Rodrigo Moya wrote: On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote: Regarding couchdb: how complete is its data model? When it first showed up, SyncEvolution had some problems with it because REV wasn't supported, if memory serves me right. IIRC, that was a bug you filed for evolution-couchdb, which didn't include the REV field, which I fixed some months ago. Does it support arbitrary vCard extensions? evolution-couchdb supports whatever Evolution supports, which has several vCard extensions (X-EVOLUTION-* fields for instance), so yes, it does I was thinking of extensions not yet used by Evolution. Let's use an example: is an extensions like X-FOOBARAPP-MY-NEW-PROPERTY going to be stored by evolution-couchdb when it appears in a vCard sent to EDS? This is relevant in several cases: 1. when extending the data model in Evolution and/or apps using libebook 2. when storing/retrieving vCards created by some other app Case 1 occurs when using EDS as backend for QtContacts, the contact API in MeeGo. I'm currently working on that binding, with the goal of getting EDS back into MeeGo. Case 2 already occurs in GNOME when synchronizing. It can be handled by SyncEvolution by declaring which properties are supported by a storage, but right now the assumption is that EDS backends are as capable as the file backend and support arbitrary extensions. As for couchdb, it's a schema-free database, so it can support whatever we want it to How hard would it be to add storing such extensions and recreating them again later? Remember that they may also contain X- parameters and that binary encoding needs to be handled. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On 04/20/2011 11:51 AM, Stef Walter wrote: [...] It seems to me the architecture of Meego SSO is very security focused. Indeed it is. [...] However I think that this could get in the way of broader adoption. In order to succeed, you would need patch every GNOME application and library to not do its own authentication (DIGEST, NTLM, OAuth, CRAM, GSSAPI, and so on...) but have them call out to the daemon. This is not impossible but requires a large amount of commitment and time by someone (probably you). It's not something that will likely happen by the various projects on their own. True, but it's also totally optional. I mean, of course the goal would be to have a centralized point for accounts configuration, but it's clear that this will happen in steps. And I don't believe that this problem is specific to the MeeGo SSO: even if you go for another (less secure) implementation, you'll still have to modify all client applications/libraries. We add some more stress on the security, but directly providing the token and handling of failing authentications should be an advantage for applications; they would actually have some code *removed*. But even if this shouldn't happen, it's again optional: SSO provides also a plain password method, so applications won't have to change much. If the goal is to have this work with the entire desktop (not just GNOME) then certain applications (think Mozilla) would be very challenging to refactor in this way. Yes. We actually wrote an extension to Mozilla to reimplement the LoginStorage by means of the accounts/SSO framework. It's not open source, but I can grant you that it was not a huge amount of code. The amount of work that this involves brings me to question the practical value of hiding the secrets from the applications. Here are some thoughts: [...] You raised a few valid points here. But IMHO, the biggest advantage of the SSO is not the increased security (which is also important of course), but especially the fact that adopting the framework will make applications' code smaller and more flexible. Once, you adopt the SSO framework, your application can change from an authentication method to the other by just changing a few lines of code (or even none, if the authentication method and its parameters are read from a configuration file). It's especially good for frameworks and applications supporting different accounts, such as Telepathy, pidgin, Evolution, F-Spot, etc. Also the handling of failed authentications would be moving to SSO (+ the missing SSO UI), so we'd have a consistent experience on all apps. I think that even if we disabled all kinds of security in the SSO daemon, it would still make a lot of sense to use it. BTW, back to security: one thing you mentioned was about OAuth secrets: yes, applications would get them, but usually they are time-bound, so they expire after some time -- while passwords usually don't. Ciao, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Di, 2011-04-19 at 09:12 -0700, Travis Reitter wrote: On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote: Another conceptual problem is that the server cannot communicate well with the user. A client might pop up rich dialogs and ask the user for help in cases that it cannot decide automatically (but designing such a dialog is an unsolved problem). SyncML servers (and probably other servers, too) don't have that option and instead fall back to heuristics which fail inevitably in some cases. I think we'll have done something wrong if we need to ask the user to resolve their own conflicts (especially on a semi-regular basis in a process that may have started automatically in the background). Agreed. It's more a theoretic advantage of having the possibility to do it. More important is perhaps another aspect: with current servers, the server admins (or perhaps even developers) decided how conflicts get resolved. Some of them throw away data to avoid duplicates. That's not a policy that I, as a user, would choose if I was asked, while for other users it might be appropriate. With conflict resolution in the client, it is much easier to give the user the choice. But that's still a pretty power-user-ish option. In practice, with SyncEvolution in MeeGo Netbook, we did something else: instead of letting a sync proceed in a mode where heuristics are needed (slow sync), we explain that there was a problem (without necessarily going into details) and then let the user decide whether he wants to go ahead with the local or remote set of data or wants to let the server do the matching between the two sets. I think for the (hopefully) rare cases where this decision is necessary, users can understand the problem and make an educated choice based on where they made the most recent changes to the data. I'm confident that sync is one of those things that users might request if you give them a checklist of features, but wouldn't want to deal with if they had to sort through hard-to-communicate conflict resolution dialogs like this. I think backups fall into a similar category, except they're even simpler. We all know how well most people deal with those :) Incidentally, there are also automatic backups made as part of syncing, in case that something really goes wrong... ;-) -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Wed, 2011-04-20 at 11:54 +0200, Patrick Ohly wrote: On Mi, 2011-04-20 at 10:58 +0200, Rodrigo Moya wrote: On Tue, 2011-04-19 at 17:06 +0200, Patrick Ohly wrote: On Di, 2011-04-19 at 16:34 +0200, Rodrigo Moya wrote: On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote: Regarding couchdb: how complete is its data model? When it first showed up, SyncEvolution had some problems with it because REV wasn't supported, if memory serves me right. IIRC, that was a bug you filed for evolution-couchdb, which didn't include the REV field, which I fixed some months ago. Does it support arbitrary vCard extensions? evolution-couchdb supports whatever Evolution supports, which has several vCard extensions (X-EVOLUTION-* fields for instance), so yes, it does I was thinking of extensions not yet used by Evolution. Let's use an example: is an extensions like X-FOOBARAPP-MY-NEW-PROPERTY going to be stored by evolution-couchdb when it appears in a vCard sent to EDS? not right now, it's a bug indeed. But the desktopcouch spec in freedesktop has a field called 'application_annotations', where we could store any field evolution-couchdb doesn't understand. This is relevant in several cases: 1. when extending the data model in Evolution and/or apps using libebook 2. when storing/retrieving vCards created by some other app Case 1 occurs when using EDS as backend for QtContacts, the contact API in MeeGo. I'm currently working on that binding, with the goal of getting EDS back into MeeGo. Case 2 already occurs in GNOME when synchronizing. It can be handled by SyncEvolution by declaring which properties are supported by a storage, but right now the assumption is that EDS backends are as capable as the file backend and support arbitrary extensions. As for couchdb, it's a schema-free database, so it can support whatever we want it to How hard would it be to add storing such extensions and recreating them again later? Remember that they may also contain X- parameters and that binary encoding needs to be handled. not hard at all, we just need to define where they are stored (that is application_annotations/evolution, for instance) and add the code to evolution-couchdb to do so ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Contributions
Hi: a few days ago I read about the platform-wide feature proposal period of gnome 3.2 and I want to know how can someone using gnome not gnome developer propose something to get included into gnome ? I have some ideas, and I want to discuss those with gnome developers, how do I do that ? Erick -- El derecho de expresar nuestros pensamientos tiene algún significado tan sólo si somos capaces de tener pensamientos propios. El miedo a la libertad, Erich Fromm ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Contributions
Hi! a few days ago I read about the platform-wide feature proposal period of gnome 3.2 and I want to know how can someone using gnome not gnome developer propose something to get included into gnome ? I have some ideas, and I want to discuss those with gnome developers, how do I do that ? This is the correct mailing list for this kind of discussion. You should check was has been discussed already before proposing something (see [1]). If it is something that is not an overall gnome feature but specific to some kind of application you should consider using a more specialised mailing list/bugzilla component. Regards, Johannes [1] http://live.gnome.org/ThreePointOne/Features (note: this is not a brainstorming place!) 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
Gnome3 session and gnome shell crash on sparc64: FreeBSD 9_Current
gnome-session: http://slexy.org/view/s20L2lzAD0 gnome-shell: http://slexy.org/view/s21z3rtwzu Compiler runs with default values. Two UltraSPARCIII 750MHz cpus. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome3 session and gnome shell crash on sparc64: FreeBSD 9_Current
Le mercredi 20 avril 2011 à 15:52 -0400, Super Bisquit a écrit : gnome-session: http://slexy.org/view/s20L2lzAD0 gnome-shell: http://slexy.org/view/s21z3rtwzu Compiler runs with default values. Two UltraSPARCIII 750MHz cpus. Thanks for the report, but please use Bugzilla to report crashes. This list is meant to discuss GNOME development. Also, you need to type at least 'ba' in gdb to get a useful output. 'n' doesn't do anything when the program has crashed. You may also need to install debugging symbols. See http://live.gnome.org/GettingTraces Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome3 session and gnome shell crash on sparc64: FreeBSD 9_Current
Thanks. Will do. On 4/20/11, Milan Bouchet-Valat nalimi...@club.fr wrote: Le mercredi 20 avril 2011 à 15:52 -0400, Super Bisquit a écrit : gnome-session: http://slexy.org/view/s20L2lzAD0 gnome-shell: http://slexy.org/view/s21z3rtwzu Compiler runs with default values. Two UltraSPARCIII 750MHz cpus. Thanks for the report, but please use Bugzilla to report crashes. This list is meant to discuss GNOME development. Also, you need to type at least 'ba' in gdb to get a useful output. 'n' doesn't do anything when the program has crashed. You may also need to install debugging symbols. See http://live.gnome.org/GettingTraces Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.2: gjs/seed
Hi, So speaking as someone who was motivated to make writing GNOME apps easier, I'm not very happy with how things turned out with the mix of gjs/seed/python/introspection/gtk3. In this mail I just want to focus on the gjs/seed situation. Before 3.0 we chose to use gjs for gnome-shell for a variety of reasons: 1) gjs existed 2) seed didn't 3) Litl contributed a number of engineers to gjs 4) While I know some GNOME contributors here don't like Mozilla, in the big picture their mission and culture is *MUCH* more aligned with ours than Apple, at least 5) The Spidermonkey-specific JavaScript extensions like const and let were useful and cool 6) Many GNOME consumers actually ship Firefox and not Epiphany, and so we were technically aligned on that end (yes, this is the GNOME is a bucket of parts mindset, which I would really like to fix, but that's a separate issue) But let me cut to the chase and say that I think we'd at least consider realigning on seed for 3.2 for gnome-shell (and by extension, mark gjs as deprecated at least in GNOME). There are, however, nontrivial issues. First is that actually in good news on the gjs front, a standalone Spidermonkey release was just made recently, and I have a patch ready to use it in gjs: https://bugzilla.gnome.org/show_bug.cgi?id=646369 In contrast though, /usr/bin/seed appears to actually link to WebKit, which would be a painful dependency to have for gnome-shell, since it'd be insane to try using it inside the compositor process. This may (hopefully) be fixable. Even tougher would be unwinding the Spidermonkey let/const and generator usage inside gnome-shell, but we dug the hole, we can dig it out. That covers reasons 1,2 and 5. As far as reason 3), they're not as active anymore (probably gjs basically works for them), and for 6) I think we need to change this anyways. This leaves reason 4) which I admit is just a feeling. So - seed/gjs contributors - what do you think? One thing I'm not totally happy with is the organic growth in API in both seed and gjs. seed for example added an os module with e.g. fork which I think is totally wrong; it's just broken to fork() a GNOME app, since it conflicts with threads, etc. If we're going to do some unification, we should also prune a lot of cruft. If there are bits missing from GNOME (like GIO is really missing both Console and Process classes), we need to add them. == Dynamic Languages in GNOME == One thing that's worth addressing though (again) is the question do we need both Python and JavaScript?. The uptake of both seed and gjs has been relatively low; lower than Python at least for scripting GNOME apps. However, I think at least one the core reason for working on JavaScript remains that *we define the platform*. Python comes with a vast API, a lot of it really old and crufty, but even more importantly, large parts of it are *wrong* to use in GNOME. For example, we don't want people to use Python's mostly-POSIX-like wrappers for IO, we want people to use GIO, so it doesn't block the mainloop. We don't want people to use Python's webbrowser module, its multiprocessing module (which totally breaks things like X and DBus since it uses a bare fork()), etc. On the other side of the coin though, I think we largely failed to make JavaScript a compelling way to write apps. The language is only a part of the question, and it's really not a large one. We need to focus more on a build/deploy story, and less on /usr/bin/gjs. By build I mean we really shouldn't be leaving it up to app authors to figure out how to use Automake with gjs/seed and to do imports.gi.Gtk. Deploy is another story. The other reasons: * ecosystem: The industry adoption is reflected in all the work that goes into JIT compilers, as well as people simply learning the language * Better engine internals - the global interpreter lock in cPython really hurts it as far as a future in a multicore world (No, unlike what you've read in some parts of the internets, a reason to add JavaScript wasn't to attract web developers explicitly; but they are part of the industry) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Contributions
Hi Erik, a few days ago I read about the platform-wide feature proposal period of gnome 3.2 and I want to know how can someone using gnome not gnome developer propose something to get included into gnome ? I have some ideas, and I want to discuss those with gnome developers, how do I do that ? The features we are currently tracking are more than mere ideas, but still, if there's any particular idea you have, and you think it makes sense to consider it for GNOME (and if it's not limited to a single module, as you'd better contact the module owners for that), please do tell about it here, on desktop-devel-list. Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
