Re: (not) proposing Snowy for GNOME 3.0
On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote: == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app.I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. yes, maybe it would make sense to have a generic sync API, so that the same API and server could be used for syncing notes, contacts, calendar events, etc. I don't think that would make a monster app, if it's just a syncing server implementing a single API, wouldn't it? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (not) proposing Snowy for GNOME 3.0
On Fri, Oct 22, 2010 at 3:27 AM, Rodrigo Moya rodr...@gnome-db.org wrote: On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote: == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app. I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. yes, maybe it would make sense to have a generic sync API, so that the same API and server could be used for syncing notes, contacts, calendar events, etc. I don't think that would make a monster app, if it's just a syncing server implementing a single API, wouldn't it? I disagree. Not every app has the same sync needs. I think most apps could get away with a simpler sync than what Tomboy currently uses. And even if we had a generic sync API, we'd end up being forced to either store giant JSON strings in the database, or be forced to use an unstructured DB like Couch, or have the model for each data type defined in one app. All of these have potential downsides. But my experience is limited to sync for one app, so I could certainly be wrong here. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (not) proposing Snowy for GNOME 3.0
On Fri, 2010-10-22 at 12:27 +0200, Rodrigo Moya wrote: On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote: == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app.I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. yes, maybe it would make sense to have a generic sync API, so that the same API and server could be used for syncing notes, contacts, calendar events, etc. I don't think that would make a monster app, if it's just a syncing server implementing a single API, wouldn't it? I'm not sure but there was some time ago part of implementation in CouchDB (there is evolution-couchdb etc.). At least the replication could be done by standard tool (like couchdb) and the web GUI will contact with the same standard backend. It may or may not be couchdb but couchdb implementations on client side already exists. So basicly it would be reimplementation of Ubuntu One on some license (AGPL?). Regatds 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
(not) proposing Snowy for GNOME 3.0
Hey Folks, == Intro == I think it's a bit premature to propose an entirely new type of module and moduleset in GNOME, but I think it is not a bad time to discuss what a web app moduleset might be like. I expect I'll propose Snowy for real for 3.2, after we have dogfooded our hypothetical Tomboy Online release plan (see below). As a reminder, if you are interested in joining the current Tomboy Online alpha, you are welcome to fill out our survey here: https://spreadsheets.google.com/viewform?formkey=dFZleG05V196b3g4VUFSTHhzcTRFMmc6MQ == Draft Proposal == Purpose: Snowy [0] is a Python/Django web app for synchronizing your Tomboy notes. It provides read access to your note collection through your browser, and will soon have note editing and sharing functionality as well. While it can be deployed by users on their own servers, the primary focus is a GNOME-hosted version called Tomboy Online, providing free note sync for all Tomboy users. Sync is achieved through a RESTful API [1] designed with feedback from Rodrigo Moya and Stuart Langridge from Canonical, who have implemented the same API in Ubuntu One. Tomboy and Conboy (third-party Maemo client) have been syncing over this API for over a year now, and recently Tomdroid (third-party Android client) released sync support as well. Target: hypothetical web release set Dependencies: Django and various third-party Django libraries, a web server, a database (TODO: Fill in with actual deps when actually proposing) Resource Usage: Snowy is fully GNOME-hosted, including git, ftp, bugzilla, mailing list, and even Tomboy Online is hosted on GNOME infrastructure. Adoption: N/A GNOME-ness: We have work to do to get translations hooked into GNOME infrastructure. I'm not entirely sure yet how documentation should be handled. Snowy development is closely tied to Tomboy development (same maintainer, same initial userbase). What GNOME-ness means for a web app is something that still needs to be determined, imho. 3.0-readiness: N/A License: AGPL == Tomboy Online Release Plan == In initial conversations about how we plan to manage releases for Tomboy Online, we have come up with this plan: * Snowy follows the GNOME release schedule. * Tomboy Online will only ever run official released code. * Because of the above, we may find it necessary to release more frequently than typical modules. * In the VM provided by GNOME, we run two instances of Tomboy Online: www.tomboy-online.org and edge.tomboy-online.org . These instances have completely separate user/note databases. * www.tomboy-online.org will only run stable releases. * edge.tomboy-online.org will run the latest development release (except in the case where stable is newer/edgier). * Because of the above, we may find it necessary to very actively maintain the stable branch. * Probably, we will run a new .0 stable release for a couple of weeks on edge.t-o before deploying to www.t-o. There shouldn't be any need for such a delay for point releases after .0. We think this will work well. Users who want to try the latest features can use edge.t-o, and users who want stability and don't mind waiting 6 months for new features can use www.t-o, but can still rest assured that they will receive timely fixes for security and stability issues they may encounter. == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app.I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. Clearly, if we want to succeed on the web, we'll need to have a defined web platform. But I don't think we're there yet. I'm getting sleepy and feeling kind of rambly, so I'm just going to send this and go to sleep. Any and all feedback is welcome. Sandy [0] http://live.gnome.org/Snowy [1] http://live.gnome.org/Tomboy/Synchronization/REST ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
