Re: (not) proposing Snowy for GNOME 3.0
- From: Sandy Armstrong <sanfordarmstrong gmail com>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: Desktop Devel <desktop-devel-list gnome org>
- Subject: Re: (not) proposing Snowy for GNOME 3.0
- Date: Fri, 22 Oct 2010 03:42:02 -0700
On Fri, Oct 22, 2010 at 3:27 AM, Rodrigo Moya <rodrigo 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]