From john.stowers@gmail.com Mon Mar 3 10:45:34 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4FCE57500FF for ; Mon, 3 Mar 2008 10:45:34 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=2 tests=[BAYES_50=0.001, HTML_10_20=1.351, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 8966 hrs), (distance 12, link: (Google 2)), [209.85.200.172] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqPKFtqzwHUl for ; Mon, 3 Mar 2008 10:45:29 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by menubar.gnome.org (Postfix) with ESMTP id 6052C7500CE for ; Mon, 3 Mar 2008 10:45:23 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so6258151wfa.9 for ; Mon, 03 Mar 2008 02:45:22 -0800 (PST) Received: by 10.142.11.2 with SMTP id 2mr8923611wfk.223.1204541121858; Mon, 03 Mar 2008 02:45:21 -0800 (PST) Received: by 10.142.108.2 with HTTP; Mon, 3 Mar 2008 02:45:21 -0800 (PST) Message-ID: <7e40b04b0803030245xf852fe0xdc04a017796a6ae0@mail.gmail.com> Date: Mon, 3 Mar 2008 23:45:21 +1300 From: "John Stowers" To: Conduit Subject: My S{sick,lack}ness MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21332_15600991.1204541121854" X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 10:45:34 -0000 ------=_Part_21332_15600991.1204541121854 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Guys, Just a note to say that I have been sick for the last week, and have not had any will to do hacking. I hope to be back soon. Regards John p.s. Anyone working on anything interesting, it will cheer me up p.p.s Thanks to Brent for his work on the docs ( http://live.gnome.org/action/info/Conduit/Documentation), its my first priority to get this in SVN when I am back. Anyone is encouraged to edit the wiki ------=_Part_21332_15600991.1204541121854 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Guys,

Just a note to say that I have been sick for the last week, and have not had any will to do hacking. I hope to be back soon.

Regards

John

p.s. Anyone working on anything interesting, it will cheer me up
p.p.s Thanks to Brent for his work on the docs (http://live.gnome.org/action/info/Conduit/Documentation), its my first priority to get this in SVN when I am back. Anyone is encouraged to edit the wiki
------=_Part_21332_15600991.1204541121854-- From creeva@gmail.com Mon Mar 3 16:52:44 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 87A1F7500D1 for ; Mon, 3 Mar 2008 16:52:44 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=2 tests=[BAYES_20=-0.74, HTML_40_50=0.496, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 4764 hrs), (distance 13, link: (Google 2)), [209.85.198.186] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMZgpxGUH62L for ; Mon, 3 Mar 2008 16:52:39 +0000 (GMT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by menubar.gnome.org (Postfix) with ESMTP id 179A6750140 for ; Mon, 3 Mar 2008 16:52:39 +0000 (GMT) Received: by rv-out-0910.google.com with SMTP id k20so78910rvb.3 for ; Mon, 03 Mar 2008 08:52:36 -0800 (PST) Received: by 10.141.22.1 with SMTP id z1mr125200rvi.277.1204563156425; Mon, 03 Mar 2008 08:52:36 -0800 (PST) Received: by 10.70.68.3 with HTTP; Mon, 3 Mar 2008 08:52:36 -0800 (PST) Message-ID: <2510ddab0803030852l1e0e982cwffe592fa346659b1@mail.gmail.com> Date: Mon, 3 Mar 2008 11:52:36 -0500 From: "Brent Gueth" To: "John Stowers" Subject: Re: My S{sick,lack}ness In-Reply-To: <7e40b04b0803030245xf852fe0xdc04a017796a6ae0@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21874_5263566.1204563156523" References: <7e40b04b0803030245xf852fe0xdc04a017796a6ae0@mail.gmail.com> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 16:52:44 -0000 ------=_Part_21874_5263566.1204563156523 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Don't worry I've slacked off this last week also - on a positive note by wife ordered an n800 for herself so I'll be able to do some testing with that. 2008/3/3 John Stowers : > Hi Guys, > > Just a note to say that I have been sick for the last week, and have not > had any will to do hacking. I hope to be back soon. > > Regards > > John > > p.s. Anyone working on anything interesting, it will cheer me up > p.p.s Thanks to Brent for his work on the docs ( > http://live.gnome.org/action/info/Conduit/Documentation), its my first > priority to get this in SVN when I am back. Anyone is encouraged to edit the > wiki > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > > ------=_Part_21874_5263566.1204563156523 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Don't worry I've slacked off this last week also - on a positive note by wife ordered an n800 for herself  so I'll be able to do some testing with that.

2008/3/3 John Stowers <john.stowers@gmail.com>:
Hi Guys,

Just a note to say that I have been sick for the last week, and have not had any will to do hacking. I hope to be back soon.

Regards

John

p.s. Anyone working on anything interesting, it will cheer me up
p.p.s Thanks to Brent for his work on the docs (http://live.gnome.org/action/info/Conduit/Documentation), its my first priority to get this in SVN when I am back. Anyone is encouraged to edit the wiki

_______________________________________________
Conduit-list mailing list
Conduit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/conduit-list


------=_Part_21874_5263566.1204563156523-- From john.stowers@gmail.com Tue Mar 4 10:58:37 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 89AEB750163 for ; Tue, 4 Mar 2008 10:58:37 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 9208 hrs), (distance 12, link: (Google 2)), [209.85.200.172] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdK15M0ujCBr for ; Tue, 4 Mar 2008 10:58:31 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by menubar.gnome.org (Postfix) with ESMTP id 44C327500E5 for ; Tue, 4 Mar 2008 10:58:31 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so851927wfa.9 for ; Tue, 04 Mar 2008 02:58:29 -0800 (PST) Received: by 10.142.78.10 with SMTP id a10mr511625wfb.37.1204628309900; Tue, 04 Mar 2008 02:58:29 -0800 (PST) Received: by 10.142.108.2 with HTTP; Tue, 4 Mar 2008 02:58:29 -0800 (PST) Message-ID: <7e40b04b0803040258r625cb0dci8d3e907074950482@mail.gmail.com> Date: Tue, 4 Mar 2008 23:58:29 +1300 From: "John Stowers" To: "Brent Gueth" Subject: Re: My S{sick,lack}ness In-Reply-To: <2510ddab0803030852l1e0e982cwffe592fa346659b1@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24473_24844141.1204628309891" References: <7e40b04b0803030245xf852fe0xdc04a017796a6ae0@mail.gmail.com> <2510ddab0803030852l1e0e982cwffe592fa346659b1@mail.gmail.com> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 10:58:37 -0000 ------=_Part_24473_24844141.1204628309891 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Ohh and I just saw this http://wiki.mandriva.com/en/2008.1_What's_New#Conduit Shiny shiny. I will try and get a new release out ASAP with the new docs John On Tue, Mar 4, 2008 at 5:52 AM, Brent Gueth wrote: > Don't worry I've slacked off this last week also - on a positive note by > wife ordered an n800 for herself so I'll be able to do some testing with > that. > > 2008/3/3 John Stowers : > > > Hi Guys, > > > > Just a note to say that I have been sick for the last week, and have not > > had any will to do hacking. I hope to be back soon. > > > > Regards > > > > John > > > > p.s. Anyone working on anything interesting, it will cheer me up > > p.p.s Thanks to Brent for his work on the docs ( > > http://live.gnome.org/action/info/Conduit/Documentation), its my first > > priority to get this in SVN when I am back. Anyone is encouraged to edit the > > wiki > > > > _______________________________________________ > > Conduit-list mailing list > > Conduit-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/conduit-list > > > > > ------=_Part_24473_24844141.1204628309891 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Ohh and I just saw this

http://wiki.mandriva.com/en/2008.1_What's_New#Conduit

Shiny shiny. I will try and get a new release out ASAP with the new docs

John

On Tue, Mar 4, 2008 at 5:52 AM, Brent Gueth <creeva@gmail.com> wrote:
Don't worry I've slacked off this last week also - on a positive note by wife ordered an n800 for herself  so I'll be able to do some testing with that.

2008/3/3 John Stowers <john.stowers@gmail.com>:
Hi Guys,

Just a note to say that I have been sick for the last week, and have not had any will to do hacking. I hope to be back soon.

Regards

John

p.s. Anyone working on anything interesting, it will cheer me up
p.p.s Thanks to Brent for his work on the docs (http://live.gnome.org/action/info/Conduit/Documentation), its my first priority to get this in SVN when I am back. Anyone is encouraged to edit the wiki

_______________________________________________
Conduit-list mailing list
Conduit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/conduit-list



------=_Part_24473_24844141.1204628309891-- From Jijun.Yu@Sun.COM Wed Mar 5 07:01:13 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 430127500A3 for ; Wed, 5 Mar 2008 07:01:13 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=2 tests=[AWL=0.358, BAYES_00=-2.599, L_P0F_Unix=-1, UNPARSEABLE_RELAY=0.001] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 19, link: ethernet/modem), [192.18.19.6] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze3qF-TBx0TF for ; Wed, 5 Mar 2008 07:01:06 +0000 (GMT) Received: from sineb-mail-1.sun.com (sineb-mail-1.sun.com [192.18.19.6]) by menubar.gnome.org (Postfix) with ESMTP id 3806B75017B for ; Wed, 5 Mar 2008 07:01:05 +0000 (GMT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m25718we018643 for ; Wed, 5 Mar 2008 07:01:08 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JX800101WJKA700@mail-apac.sun.com> (original mail from Jijun.Yu@Sun.COM) for conduit-list@gnome.org; Wed, 05 Mar 2008 15:01:02 +0800 (SGT) Received: from [129.158.217.211] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JX800BMSWTQMHZ3@mail-apac.sun.com>; Wed, 05 Mar 2008 15:01:02 +0800 (SGT) Date: Wed, 05 Mar 2008 15:01:00 +0800 From: jijun yu Subject: Re: My S{sick,lack}ness In-reply-to: <7e40b04b0803030245xf852fe0xdc04a017796a6ae0@mail.gmail.com> Sender: Jijun.Yu@Sun.COM To: John Stowers Message-id: <47CE452C.7070607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <7e40b04b0803030245xf852fe0xdc04a017796a6ae0@mail.gmail.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 07:01:13 -0000 John, Sorry to hear that! Hope you recover back soon! - Jerry John Stowers wrote: > Hi Guys, > > Just a note to say that I have been sick for the last week, and have > not had any will to do hacking. I hope to be back soon. > > Regards > > John > > p.s. Anyone working on anything interesting, it will cheer me up > p.p.s Thanks to Brent for his work on the docs > (http://live.gnome.org/action/info/Conduit/Documentation), its my > first priority to get this in SVN when I am back. Anyone is encouraged > to edit the wiki > ------------------------------------------------------------------------ > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > From admin@kubasik.net Wed Mar 5 08:54:06 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C4B94750094 for ; Wed, 5 Mar 2008 08:54:06 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=2 tests=[BAYES_50=0.001, TW_JS=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 9446 hrs), (distance 17, link: (Google 2)), [72.14.220.152] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sGZvZdwhcrB for ; Wed, 5 Mar 2008 08:54:01 +0000 (GMT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by menubar.gnome.org (Postfix) with ESMTP id DA7B4750080 for ; Wed, 5 Mar 2008 08:54:00 +0000 (GMT) Received: by fg-out-1718.google.com with SMTP id d23so1315644fga.33 for ; Wed, 05 Mar 2008 00:53:58 -0800 (PST) Received: by 10.86.84.5 with SMTP id h5mr2542066fgb.27.1204707237896; Wed, 05 Mar 2008 00:53:57 -0800 (PST) Received: by 10.86.95.4 with HTTP; Wed, 5 Mar 2008 00:53:57 -0800 (PST) Message-ID: <78b1a24a0803050053y1a2865f2w6b257bd09a33a56b@mail.gmail.com> Date: Wed, 5 Mar 2008 01:53:57 -0700 From: "Kevin Kubasik" Sender: admin@kubasik.net To: conduit-list@gnome.org, gimmie@googlegroups.com, "Dashboard Hackers" Subject: SuperDataDaemonThing - Lets Plan MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 2005f6ff57576cb8 X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 08:54:07 -0000 1) Eventually we will pick a name But seriously ladys and forks ;) the SuperDataDaemonThingl [1](sddt for the rest of this mail) is a wicked awesome idea. An integral part of the online desktop and the changing way we use computers. I know I'm preaching to the choir a bit with this sentiment, but we all know how frustrating it is to see 6 Flickr API's all on the desktop, each authenticating and downloading all the photos separately, and most frustrating of all, each fixing the same bug separately over and over. There are tons of great arguments for doing all this in C or as a collection of libraries, or not at all, but they pale in comparison to someone actually starting to do something and writing code. It is under this banner of 'lets start doing something instead of just talking' that I propose the following: 1) Sddt will exist as its own process, and as a 'freestanding' project. While we might save some time just modding out a conduit interface to leverage its DataProviders, Conduit has a very different purpose, and while it would work fine for Gimmie and Conduit and maybe the next 3 programs that come along, this interface needs to be generic, and so does its backend. 2) All that being said, starting from scratch is clearly a mistake, as Conduit has already implemented a great deal of logic when it comes to talking to a variety of endpoints. My 'solution' is that we make sddt a phased project that will eventually be more or less rewritten, but still highly functional in its infancy. * The first iteration of sddt will be little more than a thin DBus wrapper, a kind of glue for everyone. We don't implement caching or connection pooling, or even authentication storage within sddt itself, we just use dbus whereever possible, and libraries where we must to offer an initial set of DataProviders. They will be ugly, and slow, and in no way better than implementations that people are currently using. However, this gives us a functional platform to get API feedback on, and to provide a complete featureset when applications decide to migrate. * The second phase is the implementation is the consolidation of backends and caching, The goal being that (especially for remote services like flickr) we should be able to respond to calls almost immediately by using a local sqlitedb or even just pickle. Then we can queue a refresh of the remote source, if changes are made, we fire the appropriate events. This is a big step, and will require significant amounts of new code. However, because we can implement it one DataProvider at a time, we won't be pressed to somehow produce all that caching code in one release cycle. * Finally, we do something with authentication, make some prettier config UI's etc. etc. make it into a real application. I know its not a perfect, but I spent a few hours this week trying to figure out the best launching point for this (3 failed attempts later) I realized that I couldn't just start from scratch, and I would have to screw with far too much of conduit's internals to make it do what we want. (However, a copy of its Dataproviders is a good starting point for several of our more common backends) Ok, are we still alive? Does this sound even remotely sane? The idea is that we design a rockin public API, and we make that as functional as humanly possible as soon as possible. Then, we slowly repair the backend, bit by bit. This isn't coming from some person experience, its just an idea, so feel free to abuse it as one. Now, for implementation of the actual DBus API. 1) The interface for finding and being notified of DataProvider's presence will be much akin to Conduit's as mentioned on the Wiki. 2) Once the user has a DataProvider, it seems like a small expansion of the basic CRUD is a good start: * get_all * get * put * delete * refresh (Anyone who's worked on conduits internals gets a tingle in their spine ;) ) 3) Jc2K had a great idea and turned me on to json-glib. While the above interface is complete, I'm sure everyone noticed that in most cases get is going to be returning one mammoth tuple, which isn't very user-friendly A much cleaner way is to make all of our DataTypes GObjects and use json-glib to string them over the wire. Now this does present 2 main concerns 1) its Gnome specific, I feel dirty using dBus to be desktop specific, and 2) its very different from most dBus applications. And while it is easier to deserialize a string than it is to try and manage an enormous struct or tuple, people have much more familiarity with the structs and tuples. For the sake of shockingly beautiful client code, my vote is towards json-glib (note that means we get lots of free translation into most popular languages, its pretty safe to say if they have dbus bindings they have gobject bindings as well.) Of course, it seemed odd to me that there wasn't already a better way of doing this over dBus, I'm still pretty new to it on the whole, so I really can't say I've got the finer points down. On this note, I have a patch for an initial set of python bindings to json-glib, its only about 70% of the api as of now, but it should be pretty easy to finish, I'm just getting bogged down in C and odd Makefile trickery, so anyone who's particularly literate in one or both, 5 minutes and some eyeballs would be much appreciated. [2] Again, following conduit's lead on this, I would think that events are best handled in a tree of interfaces. What to people think? I'd love to get in at the ground level on this one, but I wanna make sure we have a consensus on what applications could use/need and how to best provide that. Once we start to get a better idea of what form this will take its easy to split up the work ;) [1] - http://live.gnome.org/SuperDataDaemonThing [2] - http://bugzilla.openedhand.com/show_bug.cgi?id=830 -- Kevin Kubasik http://kubasik.net/blog From john.stowers@gmail.com Wed Mar 5 10:23:34 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8E86E7500E0 for ; Wed, 5 Mar 2008 10:23:34 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001, TW_JS=0.077] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtBCo2suODMI for ; Wed, 5 Mar 2008 10:23:32 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by menubar.gnome.org (Postfix) with ESMTP id D7EFC750065 for ; Wed, 5 Mar 2008 10:23:31 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so1680680wfa.9 for ; Wed, 05 Mar 2008 02:23:30 -0800 (PST) Received: by 10.142.154.20 with SMTP id b20mr719103wfe.150.1204712610381; Wed, 05 Mar 2008 02:23:30 -0800 (PST) Received: by 10.142.108.2 with HTTP; Wed, 5 Mar 2008 02:23:30 -0800 (PST) Message-ID: <7e40b04b0803050223h3647da6fr1633f4d85f765396@mail.gmail.com> Date: Wed, 5 Mar 2008 23:23:30 +1300 From: "John Stowers" To: "Kevin Kubasik" Subject: Re: SuperDataDaemonThing - Lets Plan In-Reply-To: <78b1a24a0803050053y1a2865f2w6b257bd09a33a56b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27621_5382796.1204712610360" References: <78b1a24a0803050053y1a2865f2w6b257bd09a33a56b@mail.gmail.com> Cc: conduit-list@gnome.org, gimmie@googlegroups.com, Dashboard Hackers X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 10:23:34 -0000 ------=_Part_27621_5382796.1204712610360 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ACK on the basic idea and kudos for building on the Conduit platform! I think it is smart doing this on top of the conduit daemon because we have already done a lot of the periphial stuff needed, including configuration getting/setting, and gui configuration for those yucky dataproviders that need you to sign into a website. We also have some rather comprehensive unit tests to make sure that we continue to work with all theses online dataproviders. > 1) The interface for finding and being notified of DataProvider's > presence will be much akin to Conduit's as mentioned on the Wiki. > 2) Once the user has a DataProvider, it seems like a small expansion > of the basic CRUD is a good start: > * get_all > * get > * put > * delete > * refresh I would also add finish() to give dataproviders the ability to do some transaction if they wish, and the ability to clean up memory. > > (Anyone who's worked on conduits internals gets a tingle in their spine ;) > ) > 3) Jc2K had a great idea and turned me on to json-glib. While the > above interface is complete, I'm sure everyone noticed that in most > cases get is going to be returning one mammoth tuple, which isn't very > user-friendly A much cleaner way is to make all of our DataTypes > GObjects and use json-glib to string them over the wire. Now this does > present 2 main concerns 1) its Gnome specific, I feel dirty using dBus > to be desktop specific, and 2) its very different from most dBus > applications. And while it is easier to deserialize a string than it > is to try and manage an enormous struct or tuple, people have much > more familiarity with the structs and tuples. For the sake of > shockingly beautiful client code, my vote is towards json-glib (note > that means we get lots of free translation into most popular > languages, its pretty safe to say if they have dbus bindings they have > gobject bindings as well.) Note that I have already had this discussion with Jc2k, but I will repeat it here, as hopefully it makes more sense the second time around. Basically this strikes me as not a very good idea. The premise of my argument is that its more eficient for the application that wants the data to deal to do so with it in a standardised format, using the most suitable native libraries for the application, then it is to break all of the datatypes into tuple like form and then send them over the bus. By effficient I also mean less work. Conduit uses standardized datatypes to represent data it downloads, or we provide the ability to convert arbitary data to standardised types (vCal, iCard, etc). Within a dataprovider the only requirement is that data can be located via a locally unique ID. So et_all() returns LUIDS, and get(LUID) returns data at that LUID. Same applies for delete. I suggest we (conduit) expose a slightly modified Conduit (see the ExporterConduit iface) dbus interface over the bus that intercepts calls to get(LUID) and returns a local file URI that is the result of the conversion of the native dataprovider type into a standardised datatype such as a vCard or iCal. We take care of the caching, and the application always gets a local file URI that represents a remote piece of data. Note that (excluding caching logic) the above would be not more than an hours work from Conduits perspective, and would definately be worth investigating before spending too much time committing to the glib jason thing. If we need to expose additional metadata to calling apps than what can be expressed in a file uri then we can do either 1) add a get_metadata(LUID, key) 2) give the option of returning the LUID unmodified, i.e. before it is converted to a file. This may be a smarter solution where the LUID is standardised, and the app already has bindings to the dataprovider that conduit is providing a proxy for (e.g evolution - where caching doesnt make sense anyway). I still think this is a simpler solution than the jlib one which requires 1) thinking about how to deconstruct each datatype into a tuple/dictionary representation 2) extra DBus traffic 3) A new library and binding for each app Anyway, I would appreciate your thoughts Regards John Stowers ------=_Part_27621_5382796.1204712610360 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ACK on the basic idea and kudos for building on the Conduit platform!

I think it is smart doing this on top of the conduit daemon because we have already done a lot of the periphial stuff needed, including configuration getting/setting, and gui configuration for those yucky dataproviders that need you to sign into a website. We also have some rather comprehensive unit tests to make sure that we continue to work with all theses online dataproviders.


1) The interface for finding and being notified of DataProvider's
presence will be much akin to Conduit's as mentioned on the Wiki.
2) Once the user has a DataProvider, it seems like a small expansion
of the basic CRUD is a good start:
  * get_all
  * get
  * put
  * delete
  * refresh

I would also add finish() to give dataproviders the ability to do some transaction if they wish, and the ability to clean up memory.
 

(Anyone who's worked on conduits internals gets a tingle in their spine ;) )
3) Jc2K had a great idea and turned me on to json-glib. While the
above interface is complete, I'm sure everyone noticed that in most
cases get is going to be returning one mammoth tuple, which isn't very
user-friendly A much cleaner way is to make all of our DataTypes
GObjects and use json-glib to string them over the wire. Now this does
present 2 main concerns 1) its Gnome specific, I feel dirty using dBus
to be desktop specific, and 2) its very different from most dBus
applications. And while it is easier to deserialize a string than it
is to try and manage an enormous struct or tuple, people have much
more familiarity with the structs and tuples. For the sake of
shockingly beautiful client code, my vote is towards json-glib (note
that means we get lots of free translation into most popular
languages, its pretty safe to say if they have dbus bindings they have
gobject bindings as well.)

Note that I have already had this discussion with Jc2k, but I will repeat it here, as hopefully it makes more sense the second time around. Basically this strikes me as not a very good idea.

The premise of my argument is that its more eficient for the application that wants the data to deal to do so with it in a standardised format, using the most suitable native libraries for the application, then it is to break all of the datatypes into tuple like form and then send them over the bus. By effficient I also mean less work.

Conduit uses standardized datatypes to represent data it downloads, or we provide the ability to convert arbitary data to standardised types (vCal, iCard, etc). Within a dataprovider the only requirement is that data can be located via a locally unique ID. So et_all() returns LUIDS, and get(LUID) returns data at that LUID. Same applies for delete.

I suggest we (conduit) expose a slightly modified Conduit (see the ExporterConduit iface) dbus interface over the bus that intercepts calls to get(LUID) and returns a local file URI that is the result of the conversion of the native dataprovider type into a standardised datatype such as a vCard or iCal. We take care of the caching, and the application always gets a local file URI that represents a remote piece of data.

Note that (excluding caching logic) the above would be not more than an hours work from Conduits perspective, and would definately be worth investigating before spending too much time committing to the glib jason thing.

 If we need to expose additional metadata to calling apps than what can be expressed in a file uri then we can do either
1) add a get_metadata(LUID, key)
2) give the option of returning the LUID unmodified, i.e. before it is converted to a file. This may be a smarter solution where the LUID is standardised, and the app already has bindings to the dataprovider that conduit is providing a proxy for (e.g evolution - where caching doesnt make sense anyway).

I still think this is a simpler solution than the jlib one which requires
1) thinking about how to deconstruct each datatype into a tuple/dictionary representation
2) extra DBus traffic
3) A new library and binding for each app
 
Anyway, I would appreciate your thoughts

Regards

John Stowers

------=_Part_27621_5382796.1204712610360-- From admin@kubasik.net Wed Mar 5 11:24:29 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9CCDB750163 for ; Wed, 5 Mar 2008 11:24:29 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_JS=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 9471 hrs), (distance 19, link: (Google 2)), [72.14.220.153] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpz5bLbyM9HW for ; Wed, 5 Mar 2008 11:24:21 +0000 (GMT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by menubar.gnome.org (Postfix) with ESMTP id 444E07500A3 for ; Wed, 5 Mar 2008 11:24:20 +0000 (GMT) Received: by fg-out-1718.google.com with SMTP id d23so1380392fga.33 for ; Wed, 05 Mar 2008 03:24:18 -0800 (PST) Received: by 10.86.97.7 with SMTP id u7mr2863044fgb.54.1204716258200; Wed, 05 Mar 2008 03:24:18 -0800 (PST) Received: by 10.86.95.4 with HTTP; Wed, 5 Mar 2008 03:24:18 -0800 (PST) Message-ID: <78b1a24a0803050324p78413559tace874bfa74d81e5@mail.gmail.com> Date: Wed, 5 Mar 2008 04:24:18 -0700 From: "Kevin Kubasik" Sender: admin@kubasik.net To: "John Stowers" Subject: Re: SuperDataDaemonThing - Lets Plan In-Reply-To: <7e40b04b0803050223h3647da6fr1633f4d85f765396@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78b1a24a0803050053y1a2865f2w6b257bd09a33a56b@mail.gmail.com> <7e40b04b0803050223h3647da6fr1633f4d85f765396@mail.gmail.com> X-Google-Sender-Auth: dc1d4655e87eca37 Cc: conduit-list@gnome.org, gimmie@googlegroups.com, Dashboard Hackers X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 11:24:29 -0000 First, sorry for the long e-mail, totally looked shorter last night, I swear. ;) On Wed, Mar 5, 2008 at 3:23 AM, John Stowers wrote: > ACK on the basic idea and kudos for building on the Conduit platform! Hence the daemons strong conduit roots. Not having spent a ton of time on conduit code I should emphasize that this is largely a design/philosophy argument, not a grit-n-numbers one. 1) Conduit is awesome, and has connected to a plethora of services, this codebase is beyond invaluable. However, (imho) Conduit doesn't make sense as a desktop-wide daemon. While the daemon could still just be part of the conduit project (shipped as conduit-data-daemon or the like) I feel that it makes the most sense to separate the data access logic from the sync logic. What we have is the awesome application that has such a big niche to fill that its doing several roles from one (non-threadable) process. Again, this is just my opinion, but the other thing to worry about is making the daemon somewhat standard. If its never running then apps will never use it, to keep that service lean and mean we should only have its purpose served . I would argue that it would be significantly better for development if conduit used the daemon as its sole backend. My $0.02 > > I think it is smart doing this on top of the conduit daemon because we have > already done a lot of the periphial stuff needed, including configuration > getting/setting, and gui configuration for those yucky dataproviders that > need you to sign into a website. We also have some rather comprehensive unit > tests to make sure that we continue to work with all theses online > dataproviders. And I agree that this work is invaluable, and the last thing I want us to do is rewrite the same logic (the whole point of the daemon). As mentioned above, its more a concern of scope and purpose. I feel strongly that the universal data access point for a desktop should be headless and as lean as is feasible. It should also stick to one task and perform it well. I really have (over the course of this conversation) become quite fond of the idea of simply splitting conduit. We leave the UI/Sync element with its current Gtk and Dbus interfaces, and we simply move all the fetching/pushing to a separate process, and communicate over dbus. We expand the conduit backend daemon to fit the more generic role of desktop provider while maintaining solid ties to the Conduit system. > > > > > > 1) The interface for finding and being notified of DataProvider's > > presence will be much akin to Conduit's as mentioned on the Wiki. > > 2) Once the user has a DataProvider, it seems like a small expansion > > of the basic CRUD is a good start: > > * get_all > > * get > > * put > > * delete > > * refresh > > I would also add finish() to give dataproviders the ability to do some > transaction if they wish, and the ability to clean up memory. Certainly. > > > > > (Anyone who's worked on conduits internals gets a tingle in their spine ;) > ) > > 3) Jc2K had a great idea and turned me on to json-glib. While the > > above interface is complete, I'm sure everyone noticed that in most > > cases get is going to be returning one mammoth tuple, which isn't very > > user-friendly A much cleaner way is to make all of our DataTypes > > GObjects and use json-glib to string them over the wire. Now this does > > present 2 main concerns 1) its Gnome specific, I feel dirty using dBus > > to be desktop specific, and 2) its very different from most dBus > > applications. And while it is easier to deserialize a string than it > > is to try and manage an enormous struct or tuple, people have much > > more familiarity with the structs and tuples. For the sake of > > shockingly beautiful client code, my vote is towards json-glib (note > > that means we get lots of free translation into most popular > > languages, its pretty safe to say if they have dbus bindings they have > > gobject bindings as well.) > > Note that I have already had this discussion with Jc2k, but I will repeat it > here, as hopefully it makes more sense the second time around. Basically > this strikes me as not a very good idea. > > The premise of my argument is that its more eficient for the application > that wants the data to deal to do so with it in a standardised format, using > the most suitable native libraries for the application, then it is to break > all of the datatypes into tuple like form and then send them over the bus. > By effficient I also mean less work. > > Conduit uses standardized datatypes to represent data it downloads, or we > provide the ability to convert arbitary data to standardised types (vCal, > iCard, etc). Within a dataprovider the only requirement is that data can be > located via a locally unique ID. So et_all() returns LUIDS, and get(LUID) > returns data at that LUID. Same applies for delete. > > I suggest we (conduit) expose a slightly modified Conduit (see the > ExporterConduit iface) dbus interface over the bus that intercepts calls to > get(LUID) and returns a local file URI that is the result of the conversion > of the native dataprovider type into a standardised datatype such as a vCard > or iCal. We take care of the caching, and the application always gets a > local file URI that represents a remote piece of data. This is quite similar to my first design, my concern was (somewhat specialized, I know, but I feel like it could be common enough to cause concern) that some applications might still want to know the original url of an image, or want tagging info/other metadata. While the dbus tuple is totally workable, the thought of standardized GObjects with these properties (but _not_ the actual data) is as well. To dig up some of my experimental code, I had a Photo class that looked like so: Photo --remote_url --LUID --mtime --cached_url --tags and we simply send that across the wire, the client still handles native IO, as I don't trust dBus with hundereds of megs of photos yet ;) > > Note that (excluding caching logic) the above would be not more than an > hours work from Conduits perspective, and would definitely be worth > investigating before spending too much time committing to the glib jason > thing. A solid agree from me here, I just don't want us to toss a system that could make accessing the daemon significantly easier (most notebly in languages like C# where a struct is very different from a class) by offering up objects instead of tuples. > > If we need to expose additional metadata to calling apps than what can be > expressed in a file uri then we can do either > 1) add a get_metadata(LUID, key) That works, I would probably support a get_all_metadata() as well, to reduce the number of roundtrips. But that's just semantics. > 2) give the option of returning the LUID unmodified, i.e. before it is > converted to a file. This may be a smarter solution where the LUID is > standardised, and the app already has bindings to the dataprovider that > conduit is providing a proxy for (e.g evolution - where caching doesnt make > sense anyway). I do agree that in lots of cases, this is true. Like the photo scenario, we shouldn't copy the images out of f-spot's directory, that's redundant. However, the evolution case is one where I might argue the other direction. Ideally I would say that someone using sddt would need to know very little to nothing about the specifics of a dataproviders implementation. I would argue that the evo bindings tend to be buggy, and complicated to use. By abstracting this over a simple dbus interface it removes lots of implementation details. The other upside is this would expose a sort of 'first-class' object. So I could get all my evo and facebook contacts, and not need separate parsing logic for each. I'm not 100% sure of how to proceed here, its definatly a question of scope. I see an ideal system as offering a little more abstraction. And while its not very cheap, I would also argue that a json representation of an event is going to instantiate at least comparable to the parsing of an ical file for one event, or one file for each event. > > I still think this is a simpler solution than the jlib one which requires > 1) thinking about how to deconstruct each datatype into a tuple/dictionary > representation Thats all the json is essentially doing. Its a dictionary like so {attribute_name,value}. Where a value can represent deeper subsets of dictionaries, the 2 main differences are that json-glib is another library, and it instantiates GObjects, usable more or less the same in any system with gobject bindings available. In all honesty, as a python programmer, its no big, we have easy access dics,tuples,or GObjects. I'm just thinking about usability in C etc. Never having used dBus in C I cannot speak to it. If its not an issue, then we just do it the old school way. > 2) extra DBus traffic Wouldn't this be nominal? Json is an extremely minimalistic markup. I'll do some tests for numbers. > 3) A new library and binding for each app Major downside, and the main reason I'm completely ok w/ conventional dbus. > > Anyway, I would appreciate your thoughts > > Regards > > John Stowers Thanks for the input! > > -- Kevin Kubasik http://kubasik.net/blog From john.m.carr@gmail.com Wed Mar 5 16:11:47 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 28702750111 for ; Wed, 5 Mar 2008 16:11:47 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GV=0.077, TW_JS=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 1115 hrs), (distance 20, link: (Google 2)), [64.233.170.189] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kezVO7o+BITa for ; Wed, 5 Mar 2008 16:11:45 +0000 (GMT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.189]) by menubar.gnome.org (Postfix) with ESMTP id 8F66D7501AF for ; Wed, 5 Mar 2008 16:11:39 +0000 (GMT) Received: by rn-out-0910.google.com with SMTP id a43so279976rne.10 for ; Wed, 05 Mar 2008 08:11:37 -0800 (PST) Received: by 10.114.157.1 with SMTP id f1mr4758273wae.10.1204733495561; Wed, 05 Mar 2008 08:11:35 -0800 (PST) Received: by 10.114.168.2 with HTTP; Wed, 5 Mar 2008 08:11:35 -0800 (PST) Message-ID: <860b49b30803050811hc572d92o22556644a80c3661@mail.gmail.com> Date: Wed, 5 Mar 2008 16:11:35 +0000 From: "John Carr" Sender: john.m.carr@gmail.com To: "Kevin Kubasik" Subject: Re: SuperDataDaemonThing - Lets Plan In-Reply-To: <78b1a24a0803050324p78413559tace874bfa74d81e5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78b1a24a0803050053y1a2865f2w6b257bd09a33a56b@mail.gmail.com> <7e40b04b0803050223h3647da6fr1633f4d85f765396@mail.gmail.com> <78b1a24a0803050324p78413559tace874bfa74d81e5@mail.gmail.com> X-Google-Sender-Auth: 2428144967b3c6f3 Cc: gimmie@googlegroups.com, Dashboard Hackers , conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 16:11:47 -0000 Hi guys > > I think it is smart doing this on top of the conduit daemon because we have > > already done a lot of the periphial stuff needed, including configuration > > getting/setting, and gui configuration for those yucky dataproviders that > > need you to sign into a website. We also have some rather comprehensive unit > > tests to make sure that we continue to work with all theses online > > dataproviders. > And I agree that this work is invaluable, and the last thing I want us > to do is rewrite the same logic (the whole point of the daemon). As > mentioned above, its more a concern of scope and purpose. I feel > strongly that the universal data access point for a desktop should be > headless and as lean as is feasible. It should also stick to one task > and perform it well. I really have (over the course of this > conversation) become quite fond of the idea of simply splitting > conduit. We leave the UI/Sync element with its current Gtk and Dbus > interfaces, and we simply move all the fetching/pushing to a separate > process, and communicate over dbus. We expand the conduit backend > daemon to fit the more generic role of desktop provider while > maintaining solid ties to the Conduit system. I'm not really fussed whether "it" is in conduit (the project) or out of conduit, as long as it is sufficiently isolated. For example, at the moment closing the conduit GUI kills the daemon.. > > > 2) Once the user has a DataProvider, it seems like a small expansion > > > of the basic CRUD is a good start: > > > * get_all > > > * get > > > * put > > > * delete > > > * refresh > > > > I would also add finish() to give dataproviders the ability to do some > > transaction if they wish, and the ability to clean up memory. > Certainly. I'm not entirely sure of the role of "refresh" and "finish" in a shared daemon. Specifically, isn't it the purpose of the daemon to periodically check flickr and notify the applications that there is a new photo available? If some kind of connection operation needs to take place, I think the daemon should take care of it? Finish implies transaction, but if two apps were to call put at the same time there wouldnt be any kind of isolation.. So what are the semantics of the finish() call - could I end up "finish()ing" some other applications processes? > > The premise of my argument is that its more eficient for the application > > that wants the data to deal to do so with it in a standardised format, using > > the most suitable native libraries for the application, then it is to break > > all of the datatypes into tuple like form and then send them over the bus. > > By effficient I also mean less work. Anything that reduces the amount of work is great. And reusing VTHING formats is great. My concern is making sure everyone can work with the data we return easily. If our data can be fetched into a gobject then its available in C, C++, C#, Vala, Python, Java, and presumably more. Iterating over a vcard and into a json structure and back seems an approachable starter here, that or a glib-vcard... > > If we need to expose additional metadata to calling apps than what can be > > expressed in a file uri then we can do either > > 1) add a get_metadata(LUID, key) > That works, I would probably support a get_all_metadata() as well, to > reduce the number of roundtrips. But that's just semantics. I think the metadata is what we should get from get(uid). The file location is just a piece of meta data? Thats what i'd imagined in the photo cases anyway - you don't return the JPG data but a location and data like its tags and what not. I do think its important to have a few first class object formats, as I don't see any real value in a common transport layer but still needing custom code every where to decode the output for every endpoint we ever support. So if we have widely available libraries for dealing with vcard then every call to a contact DP could return a vcard. But if they don't, I don't really see a problem with a "codec" that repacks a VCard into a json library, which does (or can more easily, at least) have cross language libraries... So anyone familiar with dealing with the VTASK format and C# (for an experimental tasky backend that poked conduits Evolution DP)... > > 2) give the option of returning the LUID unmodified, i.e. before it is > > converted to a file. This may be a smarter solution where the LUID is > > standardised, and the app already has bindings to the dataprovider that > > conduit is providing a proxy for (e.g evolution - where caching doesnt make > > sense anyway). I think this is the case where you argued that an app should still have to use python-evolution, which I presume i misunderstood. If SDDT is *just* a webservice proxy with caching then evolution shouldn't be represented at all. If its something of a gvfs for "first class" data objects (contacts, events, tasks, photos, etc) then.. would gvfs expect your gvfs app to know about libsamba etc? My view is simply: There are two separate things we are talking about here, and its getting muddled into one I think: The transport abstraction and the data abstraction. The transport abstraction in conduit is in good shape, I think people (gimmie especially) would prefer to see it more asynchronous perhaps? Maybe this is a moot point (can the dbus api make the synchronous asynchronous?). Within an hour anyone with a bit of python and conduit knowledge could expose the basic CRUD model over dbus and poke any of it with stuff. Data abstraction, conduit really hasn't bothered with. Specifically in the PIM data cases. "Here is some vcard data, enjoy it". We've created thin wrappers around the real data to pass around but done nothing to make it easier for people to work with the data. When you are syncing thats enough. If we are going to function as a data abstraction then I don't think its good enough to ignore this. We need to define first class objects and how their data is passed around. Sure, passing a file over dbus is crazy, but passing a VCARD isn't so crazy. Evolution is moving to a dbus backend, as is banshee (i remember a post about how the new banshee will have a headless backend and its GUI will have an O(1) load time even with a million tracks or something?). If we can easily provide a GObject-ish way to deal with the data, even better... John From admin@kubasik.net Wed Mar 5 18:00:37 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 966D6750104 for ; Wed, 5 Mar 2008 18:00:37 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GV=0.077, TW_JS=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 9538 hrs), (distance 19, link: (Google 2)), [72.14.220.156] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9SGeGbz4fev for ; Wed, 5 Mar 2008 18:00:33 +0000 (GMT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by menubar.gnome.org (Postfix) with ESMTP id D169A75004C for ; Wed, 5 Mar 2008 18:00:32 +0000 (GMT) Received: by fg-out-1718.google.com with SMTP id d23so1569775fga.33 for ; Wed, 05 Mar 2008 10:00:30 -0800 (PST) Received: by 10.86.86.12 with SMTP id j12mr3308617fgb.33.1204740030453; Wed, 05 Mar 2008 10:00:30 -0800 (PST) Received: by 10.86.95.4 with HTTP; Wed, 5 Mar 2008 10:00:30 -0800 (PST) Message-ID: <78b1a24a0803051000k2a152172kbf02ad23b3f18670@mail.gmail.com> Date: Wed, 5 Mar 2008 11:00:30 -0700 From: "Kevin Kubasik" Sender: admin@kubasik.net To: "John Carr" Subject: Re: SuperDataDaemonThing - Lets Plan In-Reply-To: <860b49b30803050811hc572d92o22556644a80c3661@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78b1a24a0803050053y1a2865f2w6b257bd09a33a56b@mail.gmail.com> <7e40b04b0803050223h3647da6fr1633f4d85f765396@mail.gmail.com> <78b1a24a0803050324p78413559tace874bfa74d81e5@mail.gmail.com> <860b49b30803050811hc572d92o22556644a80c3661@mail.gmail.com> X-Google-Sender-Auth: 1894202b413d998e Cc: gimmie@googlegroups.com, Dashboard Hackers , conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 18:00:37 -0000 On Wed, Mar 5, 2008 at 9:11 AM, John Carr wrote: > Hi guys > > > > > I think it is smart doing this on top of the conduit daemon because we have > > > already done a lot of the periphial stuff needed, including configuration > > > getting/setting, and gui configuration for those yucky dataproviders that > > > need you to sign into a website. We also have some rather comprehensive unit > > > tests to make sure that we continue to work with all theses online > > > dataproviders. > > And I agree that this work is invaluable, and the last thing I want us > > to do is rewrite the same logic (the whole point of the daemon). As > > mentioned above, its more a concern of scope and purpose. I feel > > strongly that the universal data access point for a desktop should be > > headless and as lean as is feasible. It should also stick to one task > > and perform it well. I really have (over the course of this > > conversation) become quite fond of the idea of simply splitting > > conduit. We leave the UI/Sync element with its current Gtk and Dbus > > interfaces, and we simply move all the fetching/pushing to a separate > > process, and communicate over dbus. We expand the conduit backend > > daemon to fit the more generic role of desktop provider while > > maintaining solid ties to the Conduit system. > > I'm not really fussed whether "it" is in conduit (the project) or out > of conduit, as long as it is sufficiently isolated. For example, at > the moment closing the conduit GUI kills the daemon.. Exactly, I just don't want us to be cramming all this functionality on as an extra dbus interface attached to conduit, we need to be able to guarantee application writers that they can expect the daemon to be running. > > > > > > 2) Once the user has a DataProvider, it seems like a small expansion > > > > of the basic CRUD is a good start: > > > > * get_all > > > > * get > > > > * put > > > > * delete > > > > * refresh > > > > > > I would also add finish() to give dataproviders the ability to do some > > > transaction if they wish, and the ability to clean up memory. > > Certainly. > > I'm not entirely sure of the role of "refresh" and "finish" in a > shared daemon. Specifically, isn't it the purpose of the daemon to > periodically check flickr and notify the applications that there is a > new photo available? If some kind of connection operation needs to > take place, I think the daemon should take care of it? Finish implies > transaction, but if two apps were to call put at the same time there > wouldnt be any kind of isolation.. So what are the semantics of the > finish() call - could I end up "finish()ing" some other applications > processes? > Originally refresh was to 'force' a remote update. I think finish could still be useful information to have, lets think in terms of caches and whats kept on disk vs. in memory etc. Especially when dealing with conversions or potentially large sets. > > > > The premise of my argument is that its more eficient for the application > > > that wants the data to deal to do so with it in a standardised format, using > > > the most suitable native libraries for the application, then it is to break > > > all of the datatypes into tuple like form and then send them over the bus. > > > By effficient I also mean less work. > > Anything that reduces the amount of work is great. And reusing VTHING > formats is great. My concern is making sure everyone can work with the > data we return easily. If our data can be fetched into a gobject then > its available in C, C++, C#, Vala, Python, Java, and presumably more. > Iterating over a vcard and into a json structure and back seems an > approachable starter here, that or a glib-vcard... > > > > > If we need to expose additional metadata to calling apps than what can be > > > expressed in a file uri then we can do either > > > 1) add a get_metadata(LUID, key) > > That works, I would probably support a get_all_metadata() as well, to > > reduce the number of roundtrips. But that's just semantics. > > I think the metadata is what we should get from get(uid). The file > location is just a piece of meta data? Thats what i'd imagined in the > photo cases anyway - you don't return the JPG data but a location and > data like its tags and what not. > > I do think its important to have a few first class object formats, as > I don't see any real value in a common transport layer but still > needing custom code every where to decode the output for every > endpoint we ever support. So if we have widely available libraries for > dealing with vcard then every call to a contact DP could return a > vcard. But if they don't, I don't really see a problem with a "codec" > that repacks a VCard into a json library, which does (or can more > easily, at least) have cross language libraries... > > So anyone familiar with dealing with the VTASK format and C# (for an > experimental tasky backend that poked conduits Evolution DP)... > > > > > 2) give the option of returning the LUID unmodified, i.e. before it is > > > converted to a file. This may be a smarter solution where the LUID is > > > standardised, and the app already has bindings to the dataprovider that > > > conduit is providing a proxy for (e.g evolution - where caching doesnt make > > > sense anyway). > > I think this is the case where you argued that an app should still > have to use python-evolution, which I presume i misunderstood. If SDDT > is *just* a webservice proxy with caching then evolution shouldn't be > represented at all. If its something of a gvfs for "first class" data > objects (contacts, events, tasks, photos, etc) then.. would gvfs > expect your gvfs app to know about libsamba etc? > Not at all, which was the point I was trying to make, expect I realize it was totally muddled. > My view is simply: There are two separate things we are talking about > here, and its getting muddled into one I think: The transport > abstraction and the data abstraction. > > The transport abstraction in conduit is in good shape, I think people > (gimmie especially) would prefer to see it more asynchronous perhaps? > Maybe this is a moot point (can the dbus api make the synchronous > asynchronous?). Within an hour anyone with a bit of python and conduit > knowledge could expose the basic CRUD model over dbus and poke any of > it with stuff. Agreed. Given the nature of the GIL it strikes me as bad practice to have lots of incoming connections as well as a GUI and db interactions all in one process. However, I really don't know how conduit handles this so I'll wait until I've checked out the code to comment further. > > Data abstraction, conduit really hasn't bothered with. Specifically in > the PIM data cases. "Here is some vcard data, enjoy it". We've created > thin wrappers around the real data to pass around but done nothing to > make it easier for people to work with the data. When you are syncing > thats enough. If we are going to function as a data abstraction then I > don't think its good enough to ignore this. We need to define first > class objects and how their data is passed around. Sure, passing a > file over dbus is crazy, but passing a VCARD isn't so crazy. Evolution > is moving to a dbus backend, as is banshee (i remember a post about > how the new banshee will have a headless backend and its GUI will have > an O(1) load time even with a million tracks or something?). If we can > easily provide a GObject-ish way to deal with the data, even better... That's a great way to explain it. Now personally, as a programmer, I would prefer an object with all the metadata that can be stored in a vcard than a string of pain-in-the-butt VCARD. That's just one opinion, but I think its going to be a case-by-case thing. As far as a good general rule, I'm inclined to use something similar to the Beagle model, with every object being composed of the following information. Hit |--mtime |--uid |--content_url |--source |--type |--metadata (a dict) now the beauty of taking this 'first class' is we can provide a specific set of metadata for each type as opposed to the dict. But the biggest thing to take note of is the distinction between metadata and content. In this context not all objects have content, some are composed primarily or even completely of metadata (think contacts), As a result, they return a null content_url . In short: 1) I still feel that we need a separation between daemon/datastore and sync/gui/config. In the end, I think you guys (the conduit devs) are best suited to make the final call here. As long as we can meet the following use cases: a) User closes Conduit but leaves Gimmie open and continues to use. b) Days of uptime c) Heavy use (read multiple clients making high demands) is handled intelligently d) The 'line' is drawn somewhere which makes semantic sense and isn't just the most convenient right now. We should make a clear distinction between data/transport logic and sync logic. 2) The major point of discussion is how far to take our first class objects. We all agree that the transport logic should be hidden (akin to the gvfs model). The question remains, how do we make that data exceptionally usable to clients? Is it best in its raw form to allow the client to do what they will with it, or do we parse the data into handy objects for ease of use. 3) Authentication: No real census on this yet, but I'm assuming just using gnome-keyring and letting it handle the notification/memorization is an acceptable use case for now? 4) We need to pick an update model for our data, should we be polling automatically on our own? Do we only update when a client triggers it? (and then throw update events for other subscribed clients). While the idea of universal desktop notifications of remote changes seems awesome, I'm concerned about resources. But I wait patiently to hear what you guys think. Am I correct? > > John > -- Kevin Kubasik http://kubasik.net/blog From john.stowers@gmail.com Thu Mar 6 03:08:53 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 11A96750146 for ; Thu, 6 Mar 2008 03:08:53 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 9610 hrs), (distance 13, link: (Google 2)), [209.85.200.170] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pKQTDiD7vDi for ; Thu, 6 Mar 2008 03:08:48 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by menubar.gnome.org (Postfix) with ESMTP id F421C750126 for ; Thu, 6 Mar 2008 03:08:47 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so2220828wfa.9 for ; Wed, 05 Mar 2008 19:08:46 -0800 (PST) Received: by 10.142.126.17 with SMTP id y17mr1062474wfc.170.1204772926762; Wed, 05 Mar 2008 19:08:46 -0800 (PST) Received: by 10.142.108.2 with HTTP; Wed, 5 Mar 2008 19:08:46 -0800 (PST) Message-ID: <7e40b04b0803051908v581f4571ye37d2a35ec75a78d@mail.gmail.com> Date: Thu, 6 Mar 2008 16:08:46 +1300 From: "John Stowers" To: "Brent Gueth" Subject: Re: Ok feedback needed In-Reply-To: <7e40b04b0802202356q555128bbwbc31440c08d5c40c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29952_22244141.1204772926749" References: <2510ddab0802200821m56644ce8m73166463c8191487@mail.gmail.com> <7e40b04b0802202356q555128bbwbc31440c08d5c40c@mail.gmail.com> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 03:08:53 -0000 ------=_Part_29952_22244141.1204772926749 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > > GNOME currently uses a rather arcane XML based documentation format > called Docbook. It is a standard, but it is a bit quirky. Documents > for how to write docbook can be found at > > http://library.gnome.org/devel/gdp-handbook/stable/ > > The reason I chose to start this on the wiki is because it supports > DocBook output > > > http://live.gnome.org/Conduit/Documentation?action=show&mimetype=text/docbook > > This will take some tidying up in order to support all of the extra > formatting used in GNOME docbook manuals, but it should be a usable > start. > > Im pretty busy at university this week, so I will not get a chance to > see how easily the conversion to wiki->docbook->gnome docbook will go, > but if you havent got very far by sunday, I might have a try I have committed the first three sections of docs (What is Conduit, Understanding the Conduit Interface, Synchronizing Something), which so far have the bulk of the content, to the conduit help file. It could still be improved by linking to other sections better, but it looks good so far. I will clean up the prefs, groups, and conflict sections and add them to the help file, then I will close #515328 . I will create a new bug for documenting the dataprovider condifuration options, because I think there must be a smarter way to automatically embed the documentation for their options in the module file, and automatically take screenshots of the config windows. Anyone running conduit from SVN can check out the new docs from the help menu. It should correctly load the help even if conduit is running uninstalled. John > > > Any questions, just ask > > John > > > > > 2. Anyone know the wiki code for centering? > > _______________________________________________ > > Conduit-list mailing list > > Conduit-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/conduit-list > > > ------=_Part_29952_22244141.1204772926749 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


GNOME currently uses a rather arcane XML based documentation format
called Docbook. It is a standard, but it is a bit quirky. Documents
for how to write docbook can be found at

http://library.gnome.org/devel/gdp-handbook/stable/

The reason I chose to start this on the wiki is because it supports
DocBook output

http://live.gnome.org/Conduit/Documentation?action=show&mimetype=text/docbook

This will take some tidying up in order to support all of the extra
formatting used in GNOME docbook manuals, but it should be a usable
start.

Im pretty busy at university this week, so I will not get a chance to
see how easily the conversion to wiki->docbook->gnome docbook will go,
but if you havent got very far by sunday, I might have a try

I have committed the first three sections of docs (What is Conduit, Understanding the Conduit Interface, Synchronizing Something), which so far have the bulk of the content, to the conduit help file. It could still be improved by linking to other sections better, but it looks good so far.

I will clean up the prefs, groups, and conflict sections and add them to the help file, then I will close #515328.

I will create a new bug for documenting the dataprovider condifuration options, because I think there must be a smarter way to automatically embed the documentation for their options in the module file, and automatically take screenshots of the config windows.

Anyone running conduit from SVN can check out the new docs from the help menu. It should correctly load the help even if conduit is running uninstalled.

John

 


Any questions, just ask

John

>
>  2.  Anyone know the wiki code for centering?
>  _______________________________________________
>  Conduit-list mailing list
>  Conduit-list@gnome.org
>  http://mail.gnome.org/mailman/listinfo/conduit-list
>

------=_Part_29952_22244141.1204772926749-- From roumano@gmail.com Thu Mar 6 10:17:41 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B61247500CC for ; Thu, 6 Mar 2008 10:17:41 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Google Wireless Transcoder (2), (distance 15, link: ethernet/modem), [216.239.58.184] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvLpml62XgLn for ; Thu, 6 Mar 2008 10:17:37 +0000 (GMT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.184]) by menubar.gnome.org (Postfix) with ESMTP id 742B4750128 for ; Thu, 6 Mar 2008 10:17:31 +0000 (GMT) Received: by gv-out-0910.google.com with SMTP id r4so1718076gve.22 for ; Thu, 06 Mar 2008 02:17:29 -0800 (PST) Received: by 10.142.229.4 with SMTP id b4mr1113846wfh.184.1204798648383; Thu, 06 Mar 2008 02:17:28 -0800 (PST) Received: by 10.142.230.8 with HTTP; Thu, 6 Mar 2008 02:17:28 -0800 (PST) Message-ID: Date: Thu, 6 Mar 2008 11:17:28 +0100 From: "Roumano :)" To: conduit-list@gnome.org Subject: Ok feedback needed MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10268_27419818.1204798648385" X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 10:17:41 -0000 ------=_Part_10268_27419818.1204798648385 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I have check the new Documentation, i have found mismatch : 1) In the documentation itself, The Debugging need to be update : The python start_conduit.py is no longer works We need to do something like this : CONDUIT_LOGLEVEL=CRITICAL conduit/conduit 2) The web page isn't open correctly : Url try to be opened by my firefox : file:///work/perso/conduit/1348/%22http://www.conduit- project.org/wiki/Development%22 Log in conduit : [Web ][INFO ] Logging in using browser: system (Web.py :317) [Web ][DEBUG ] System Login for Introduction (Web.py:151) [Web ][DEBUG ] Opening http://www.conduit-project.org/wiki/Development (Web.py:17) [Web ][DEBUG ] Opened http://www.conduit-project.org/wiki/Development (Web.py:19) My application favorite ( in the gnome setting ) /usr/lib/mozilla-firefox/firefox "%s" ( if i change to firefox directly it's work's ) ( it's is working for other soft ) The Doc of Conduit it's beging to Rocks ! ------=_Part_10268_27419818.1204798648385 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,
I have check the new Documentation, i have found mismatch :

1) In the documentation itself, The Debugging need to be update :
The python start_conduit.py  is no longer works
We need to do something like this : CONDUIT_LOGLEVEL=CRITICAL conduit/conduit


2) The web page isn't open correctly :
Url try to be opened by my firefox :    file:///work/perso/conduit/1348/%22http://www.conduit-project.org/wiki/Development%22

Log in conduit :

[Web                 ][INFO   ] Logging in using browser: system (Web.py:317)
[Web                 ][DEBUG  ] System Login for Introduction (Web.py:151)
[Web                 ][DEBUG  ] Opening http://www.conduit-project.org/wiki/Development (Web.py:17)
[Web                 ][DEBUG  ] Opened http://www.conduit-project.org/wiki/Development (Web.py:19)

My application favorite ( in the gnome setting ) /usr/lib/mozilla-firefox/firefox "%s"   ( if i change to firefox directly it's work's ) ( it's is working for other soft )


The Doc of Conduit it's beging to Rocks !
------=_Part_10268_27419818.1204798648385-- From john.stowers@gmail.com Thu Mar 6 10:38:30 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5CBCE7501BC for ; Thu, 6 Mar 2008 10:38:30 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_50_60=0.134, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Google Wireless Transcoder (1), (distance 15, link: unknown-1468), [216.239.58.188] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZmXjb6ejl-E for ; Thu, 6 Mar 2008 10:38:25 +0000 (GMT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.188]) by menubar.gnome.org (Postfix) with ESMTP id BEBF37501CA for ; Thu, 6 Mar 2008 10:38:24 +0000 (GMT) Received: by gv-out-0910.google.com with SMTP id r4so1724478gve.22 for ; Thu, 06 Mar 2008 02:38:22 -0800 (PST) Received: by 10.142.82.17 with SMTP id f17mr1121903wfb.145.1204799900965; Thu, 06 Mar 2008 02:38:20 -0800 (PST) Received: by 10.142.108.2 with HTTP; Thu, 6 Mar 2008 02:38:20 -0800 (PST) Message-ID: <7e40b04b0803060238h3fd66aa8o3cca6800039deeec@mail.gmail.com> Date: Thu, 6 Mar 2008 23:38:20 +1300 From: "John Stowers" To: "Roumano :)" Subject: Re: Ok feedback needed In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30386_33495169.1204799900964" References: Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 10:38:30 -0000 ------=_Part_30386_33495169.1204799900964 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/3/6 Roumano :) : > Hello, > I have check the new Documentation, i have found mismatch : > > 1) In the documentation itself, The Debugging need to be update : > The python start_conduit.py is no longer works > We need to do something like this : CONDUIT_LOGLEVEL=CRITICAL > conduit/conduit Fixed > > > 2) The web page isn't open correctly : > Url try to be opened by my firefox : > file:///work/perso/conduit/1348/%22http://www.conduit- > project.org/wiki/Development%22 > > Log in conduit : > > [Web ][INFO ] Logging in using browser: system (Web.py > :317) > [Web ][DEBUG ] System Login for Introduction (Web.py:151) > [Web ][DEBUG ] Opening > http://www.conduit-project.org/wiki/Development (Web.py:17) > [Web ][DEBUG ] Opened > http://www.conduit-project.org/wiki/Development (Web.py:19) > > My application favorite ( in the gnome setting ) > /usr/lib/mozilla-firefox/firefox "%s" ( if i change to firefox directly > it's work's ) ( it's is working for other soft ) Please select "Use built in web browser" from the prefs menu. By putting the developer documentation into the conduit web browser it will help to identify web browser bugs so that pretty soon I can remove that option and make it the default. Thanks John > > > > The Doc of Conduit it's beging to Rocks ! > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > > ------=_Part_30386_33495169.1204799900964 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

2008/3/6 Roumano :) <roumano@gmail.com>:
Hello,
I have check the new Documentation, i have found mismatch :

1) In the documentation itself, The Debugging need to be update :
The python start_conduit.py  is no longer works
We need to do something like this : CONDUIT_LOGLEVEL=CRITICAL conduit/conduit

Fixed




2) The web page isn't open correctly :
Url try to be opened by my firefox :    file:///work/perso/conduit/1348/%22http://www.conduit-project.org/wiki/Development%22

Log in conduit :

[Web                 ][INFO   ] Logging in using browser: system (Web.py:317)
[Web                 ][DEBUG  ] System Login for Introduction (Web.py:151)
[Web                 ][DEBUG  ] Opening http://www.conduit-project.org/wiki/Development (Web.py:17)
[Web                 ][DEBUG  ] Opened http://www.conduit-project.org/wiki/Development (Web.py:19)

My application favorite ( in the gnome setting ) /usr/lib/mozilla-firefox/firefox "%s"   ( if i change to firefox directly it's work's ) ( it's is working for other soft )

Please select "Use built in web browser" from the prefs menu. By putting the developer documentation into the conduit web browser it will help to identify web browser bugs so that pretty soon I can remove that option and make it the default.

Thanks

John
 



The Doc of Conduit it's beging to Rocks !

_______________________________________________
Conduit-list mailing list
Conduit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/conduit-list


------=_Part_30386_33495169.1204799900964-- From chrismrivera@gmail.com Wed Mar 12 17:26:02 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 688D17500B7 for ; Wed, 12 Mar 2008 17:26:02 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, HTML_10_20=1.351, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 9792 hrs), (distance 13, link: (Google 2)), [209.85.142.189] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKmTac-tn7nl for ; Wed, 12 Mar 2008 17:25:59 +0000 (GMT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by menubar.gnome.org (Postfix) with ESMTP id D61E8750073 for ; Wed, 12 Mar 2008 17:25:55 +0000 (GMT) Received: by ti-out-0910.google.com with SMTP id b8so1575962tic.1 for ; Wed, 12 Mar 2008 10:25:54 -0700 (PDT) Received: by 10.151.79.6 with SMTP id g6mr4671189ybl.185.1205342752229; Wed, 12 Mar 2008 10:25:52 -0700 (PDT) Received: by 10.150.156.4 with HTTP; Wed, 12 Mar 2008 10:25:52 -0700 (PDT) Message-ID: <5f84803c0803121025v1cc862a3l7125de053787cd8@mail.gmail.com> Date: Wed, 12 Mar 2008 13:25:52 -0400 From: "Chris Rivera" To: conduit-list@gnome.org Subject: [PATCH] fix is_configured() signature in the Network module MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5832_7631091.1205342752236" X-Mailman-Approved-At: Wed, 12 Mar 2008 20:00:17 +0000 X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 17:26:02 -0000 ------=_Part_5832_7631091.1205342752236 Content-Type: multipart/alternative; boundary="----=_Part_5833_23873030.1205342752236" ------=_Part_5833_23873030.1205342752236 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi folks. The attached patch adds the missing parameters to is_configured() in NetworkModule/Server.py. It currently throws a TypeError exception without it. Please CC me on replies. Thanks, Chris ------=_Part_5833_23873030.1205342752236 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi folks.  The attached patch adds the missing parameters to is_configured() in NetworkModule/Server.py.  It currently throws a TypeError exception without it.  Please CC me on replies.

Thanks,
Chris
------=_Part_5833_23873030.1205342752236-- ------=_Part_5832_7631091.1205342752236 Content-Type: text/x-patch; name=conduit-fix-is-configured-signature.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fdq5t0z70 Content-Disposition: attachment; filename=conduit-fix-is-configured-signature.patch SW5kZXg6IGNvbmR1aXQvbW9kdWxlcy9OZXR3b3JrTW9kdWxlL1NlcnZlci5weQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBjb25kdWl0L21vZHVsZXMvTmV0d29ya01vZHVsZS9TZXJ2ZXIucHkJKHJldmlzaW9uIDEz NjkpCisrKyBjb25kdWl0L21vZHVsZXMvTmV0d29ya01vZHVsZS9TZXJ2ZXIucHkJKHdvcmtpbmcg Y29weSkKQEAgLTE1OSw3ICsxNTksNyBAQAogICAgICAgICAjU3RvcCByaWdodCBjbGljayBtZW51 CiAgICAgICAgIHJldHVybiBUcnVlCiAKLSAgICBkZWYgaXNfY29uZmlndXJlZChzZWxmKToKKyAg ICBkZWYgaXNfY29uZmlndXJlZChzZWxmLCBpc1NvdXJjZSwgaXNUd29XYXkpOgogICAgICAgICAj UHJldmVudCBpbml0aWF0aW5nIGEgc3luYyBvbiB0aGUgc2VydmVyIGVuZCBieSBwcmV0ZW5kaW5n IHdlIGFyZQogICAgICAgICAjbm90IGNvbmZpZ3VyZWQKICAgICAgICAgcmV0dXJuIEZhbHNlCg== ------=_Part_5832_7631091.1205342752236-- From chrismrivera@gmail.com Wed Mar 12 19:46:29 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 31E3D7500E9 for ; Wed, 12 Mar 2008 19:46:29 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Google Wireless Transcoder (1), (distance 15, link: unknown-1468), [216.239.58.186] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XjAl-BQG8a2 for ; Wed, 12 Mar 2008 19:46:27 +0000 (GMT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by menubar.gnome.org (Postfix) with ESMTP id 8B4447500A3 for ; Wed, 12 Mar 2008 19:46:26 +0000 (GMT) Received: by gv-out-0910.google.com with SMTP id r4so898594gve.22 for ; Wed, 12 Mar 2008 12:46:24 -0700 (PDT) Received: by 10.150.158.8 with SMTP id g8mr4765688ybe.94.1205351182711; Wed, 12 Mar 2008 12:46:22 -0700 (PDT) Received: by 10.150.156.4 with HTTP; Wed, 12 Mar 2008 12:46:22 -0700 (PDT) Message-ID: <5f84803c0803121246m276a8eb6jdd5568b8b6dd106b@mail.gmail.com> Date: Wed, 12 Mar 2008 15:46:22 -0400 From: "Chris Rivera" To: conduit-list@gnome.org Subject: [PATCH] fix avahi AddService() call MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6385_20786433.1205351182707" X-Mailman-Approved-At: Wed, 12 Mar 2008 20:00:17 +0000 X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 19:46:29 -0000 ------=_Part_6385_20786433.1205351182707 Content-Type: multipart/alternative; boundary="----=_Part_6386_21201367.1205351182707" ------=_Part_6386_21201367.1205351182707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The attached patch fixes the avahi AddService() call in Peers.py. I'm testing on openSUSE 11.0 Alpha2. The 3rd and 8th parameters of AddService() are being marshaled as ints rather than an unsigned int and an unsigned short, like the avahi introspection file says. Please CC me on any replies. Thanks, Chris ------=_Part_6386_21201367.1205351182707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The attached patch fixes the avahi AddService() call in Peers.py.  I'm testing on openSUSE 11.0 Alpha2.  The 3rd and 8th parameters of AddService() are being marshaled as ints rather than an unsigned int and an unsigned short, like the avahi introspection file says.  Please CC me on any replies.

Thanks,
Chris
------=_Part_6386_21201367.1205351182707-- ------=_Part_6385_20786433.1205351182707 Content-Type: text/x-patch; name=conduit-fix-add-service-call.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fdqatht60 Content-Disposition: attachment; filename=conduit-fix-add-service-call.patch SW5kZXg6IGNvbmR1aXQvbW9kdWxlcy9OZXR3b3JrTW9kdWxlL1BlZXJzLnB5Cj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIGNvbmR1aXQvbW9kdWxlcy9OZXR3b3JrTW9kdWxlL1BlZXJzLnB5CShyZXZpc2lvbiAxMzY5 KQorKysgY29uZHVpdC9tb2R1bGVzL05ldHdvcmtNb2R1bGUvUGVlcnMucHkJKHdvcmtpbmcgY29w eSkKQEAgLTE1OSwxMiArMTU5LDEyIEBACiAgICAgICAgIHNlbGYuZ3JvdXAuQWRkU2VydmljZSgK ICAgICAgICAgICAgICAgICBJRl9VTlNQRUMsICAgICAgICAjaW50ZXJmYWNlCiAgICAgICAgICAg ICAgICAgUFJPVE9fVU5TUEVDLCAgICAgI3Byb3RvY29sCi0gICAgICAgICAgICAgICAgMCwgICAg ICAgICAgICAgICAgICAgICAgI2ZsYWdzCisgICAgICAgICAgICAgICAgZGJ1cy5VSW50MzIoMCks ICAgICAgICAgI2ZsYWdzCiAgICAgICAgICAgICAgICAgc2VsZi5ob3N0bmFtZSwgICAgICAgICAg I25hbWUKICAgICAgICAgICAgICAgICBBVkFISV9TRVJWSUNFX05BTUUsICAgICAjc2VydmljZSB0 eXBlCiAgICAgICAgICAgICAgICAgQVZBSElfU0VSVklDRV9ET01BSU4sICAgI2RvbWFpbgogICAg ICAgICAgICAgICAgICcnLCAgICAgICAgICAgICAgICAgICAgICNob3N0Ci0gICAgICAgICAgICAg ICAgc2VsZi5wb3J0LCAgICAgICAgICAgICAgI3BvcnQKKyAgICAgICAgICAgICAgICBkYnVzLlVJ bnQxNihzZWxmLnBvcnQpLCAjcG9ydAogICAgICAgICAgICAgICAgIHN0cmluZ19hcnJheV90b190 eHRfYXJyYXkoWyJ2ZXJzaW9uPSVzIiAlIGNvbmR1aXQuVkVSU0lPTl0pCiAgICAgICAgICAgICAg ICAgKQogICAgICAgICBzZWxmLmdyb3VwLkNvbW1pdCgpCg== ------=_Part_6385_20786433.1205351182707-- From john.stowers@gmail.com Wed Mar 12 21:21:24 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C32DB7500A3 for ; Wed, 12 Mar 2008 21:21:24 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11232 hrs), (distance 13, link: (Google 2)), [209.85.200.175] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xt8DmWcV82P for ; Wed, 12 Mar 2008 21:21:20 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by menubar.gnome.org (Postfix) with ESMTP id 378657500A9 for ; Wed, 12 Mar 2008 21:21:19 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so3013456wfa.9 for ; Wed, 12 Mar 2008 14:21:18 -0700 (PDT) Received: by 10.142.221.19 with SMTP id t19mr3948089wfg.62.1205356878354; Wed, 12 Mar 2008 14:21:18 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Wed, 12 Mar 2008 14:21:18 -0700 (PDT) Message-ID: <7e40b04b0803121421l79a85fdeg812f0e616df768dc@mail.gmail.com> Date: Thu, 13 Mar 2008 10:21:18 +1300 From: "John Stowers" To: "Chris Rivera" Subject: Re: [PATCH] fix avahi AddService() call In-Reply-To: <5f84803c0803121246m276a8eb6jdd5568b8b6dd106b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_119_1490904.1205356878342" References: <5f84803c0803121246m276a8eb6jdd5568b8b6dd106b@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 21:21:25 -0000 ------=_Part_119_1490904.1205356878342 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Committed. Thanks a lot John 2008/3/13 Chris Rivera : > The attached patch fixes the avahi AddService() call in Peers.py. I'm > testing on openSUSE 11.0 Alpha2. The 3rd and 8th parameters of > AddService() are being marshaled as ints rather than an unsigned int and an > unsigned short, like the avahi introspection file says. Please CC me on any > replies. > > Thanks, > Chris > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > > ------=_Part_119_1490904.1205356878342 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Committed. Thanks a lot

John

2008/3/13 Chris Rivera <chrismrivera@gmail.com>:
The attached patch fixes the avahi AddService() call in Peers.py.  I'm testing on openSUSE 11.0 Alpha2.  The 3rd and 8th parameters of AddService() are being marshaled as ints rather than an unsigned int and an unsigned short, like the avahi introspection file says.  Please CC me on any replies.

Thanks,
Chris

_______________________________________________
Conduit-list mailing list
Conduit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/conduit-list


------=_Part_119_1490904.1205356878342-- From john.stowers@gmail.com Wed Mar 12 21:21:50 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 963DC750078 for ; Wed, 12 Mar 2008 21:21:50 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_50_60=0.134, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11232 hrs), (distance 13, link: (Google 2)), [209.85.200.175] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3ljBDN6RzGt for ; Wed, 12 Mar 2008 21:21:46 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by menubar.gnome.org (Postfix) with ESMTP id 1FD4C750004 for ; Wed, 12 Mar 2008 21:21:46 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so3013456wfa.9 for ; Wed, 12 Mar 2008 14:21:46 -0700 (PDT) Received: by 10.142.89.9 with SMTP id m9mr3943161wfb.116.1205356906014; Wed, 12 Mar 2008 14:21:46 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Wed, 12 Mar 2008 14:21:45 -0700 (PDT) Message-ID: <7e40b04b0803121421y1f93f161kd6034af6a90e404e@mail.gmail.com> Date: Thu, 13 Mar 2008 10:21:45 +1300 From: "John Stowers" To: "Chris Rivera" Subject: Re: [PATCH] fix is_configured() signature in the Network module In-Reply-To: <5f84803c0803121025v1cc862a3l7125de053787cd8@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_121_7657731.1205356906007" References: <5f84803c0803121025v1cc862a3l7125de053787cd8@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 21:21:50 -0000 ------=_Part_121_7657731.1205356906007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Committed. Thanks a lot John 2008/3/13 Chris Rivera : > Hi folks. The attached patch adds the missing parameters to > is_configured() in NetworkModule/Server.py. It currently throws a TypeError > exception without it. Please CC me on replies. > > Thanks, > Chris > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > > ------=_Part_121_7657731.1205356906007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Committed. Thanks a lot

John

2008/3/13 Chris Rivera <chrismrivera@gmail.com>:
Hi folks.  The attached patch adds the missing parameters to is_configured() in NetworkModule/Server.py.  It currently throws a TypeError exception without it.  Please CC me on replies.

Thanks,
Chris

_______________________________________________
Conduit-list mailing list
Conduit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/conduit-list


------=_Part_121_7657731.1205356906007-- From chrismrivera@gmail.com Fri Mar 14 19:23:20 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AFB837500AC for ; Fri, 14 Mar 2008 19:23:20 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.396 X-Spam-Level: X-Spam-Status: No, score=0.396 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, HTML_10_20=1.351, HTML_MESSAGE=0.001, TW_GT=0.077, TW_TK=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 3161 hrs), (distance 16, link: (Google 2)), [66.249.92.170] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-qRkbox1iCG for ; Fri, 14 Mar 2008 19:23:18 +0000 (GMT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by menubar.gnome.org (Postfix) with ESMTP id 6BE66750193 for ; Fri, 14 Mar 2008 19:23:15 +0000 (GMT) Received: by ug-out-1314.google.com with SMTP id c2so132016ugf.30 for ; Fri, 14 Mar 2008 12:23:03 -0700 (PDT) Received: by 10.150.138.8 with SMTP id l8mr6519611ybd.141.1205522582009; Fri, 14 Mar 2008 12:23:02 -0700 (PDT) Received: by 10.150.156.4 with HTTP; Fri, 14 Mar 2008 12:23:01 -0700 (PDT) Message-ID: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> Date: Fri, 14 Mar 2008 15:23:01 -0400 From: "Chris Rivera" To: conduit-list@gnome.org Subject: [PATCH] Don't force gtkmozembed in the Facebook module MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1312_2236077.1205522582024" X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 19:23:20 -0000 ------=_Part_1312_2236077.1205522582024 Content-Type: multipart/alternative; boundary="----=_Part_1313_32290294.1205522582025" ------=_Part_1313_32290294.1205522582025 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The current Facebook module forces the built-in browser to be used for authentication. This should respect the 'Use Built in Web Browser' setting in the properties dialog. Please CC me on replies. Thanks, Chris ------=_Part_1313_32290294.1205522582025 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The current Facebook module forces the built-in browser to be used for authentication.  This should respect the 'Use Built in Web Browser' setting in the properties dialog.  Please CC me on replies.

Thanks,
Chris
------=_Part_1313_32290294.1205522582025-- ------=_Part_1312_2236077.1205522582024 Content-Type: text/x-patch; name=conduit-fb-module-browser-fix.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fdqqgo640 Content-Disposition: attachment; filename=conduit-fb-module-browser-fix.patch SW5kZXg6IGNvbmR1aXQvbW9kdWxlcy9GYWNlYm9va01vZHVsZS9GYWNlYm9va01vZHVsZS5weQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBjb25kdWl0L21vZHVsZXMvRmFjZWJvb2tNb2R1bGUvRmFjZWJvb2tNb2R1 bGUucHkJKHJldmlzaW9uIDEzNzQpCisrKyBjb25kdWl0L21vZHVsZXMvRmFjZWJvb2tNb2R1bGUv RmFjZWJvb2tNb2R1bGUucHkJKHdvcmtpbmcgY29weSkKQEAgLTQzLDcgKzQzLDYgQEAKICAgICBk ZWYgX19pbml0X18oc2VsZiwgKmFyZ3MpOgogICAgICAgICBJbWFnZS5JbWFnZVNpbmsuX19pbml0 X18oc2VsZikKICAgICAgICAgc2VsZi5mYXBpID0gRmFjZWJvb2soRmFjZWJvb2tTaW5rLkFQSV9L RVksIEZhY2Vib29rU2luay5TRUNSRVQpCi0gICAgICAgIHNlbGYuYnJvd3NlciA9ICJndGttb3pl bWJlZCIKIAogICAgIGRlZiBfdXBsb2FkX3Bob3RvIChzZWxmLCB1cGxvYWRJbmZvKToKICAgICAg ICAgIiIiCkBAIC02NCw3ICs2Myw2IEBACiAKICAgICAgICAgI3dhaXQgZm9yIGxvZyBpbgogICAg ICAgICBXZWIuTG9naW5NYWdpYygiTG9nIGludG8gRmFjZWJvb2siLCB1cmwsIGxvZ2luX2Z1bmN0 aW9uPXNlbGYuX3RyeV9sb2dpbiwgCi0gICAgICAgICAgICAgICAgYnJvd3Nlcj1zZWxmLmJyb3dz ZXIsICAgICAgICNpbnN0YW5jZSB2YXIgc28gdGVzdHMgY2FuIHNldCBpdCB0byBzeXN0ZW0KICAg ICAgICAgICAgICAgICBzbGVlcF90aW1lPTQ1LCAgICAgICAgICAgICAgI2xvbmcgc2xlZXAgdGlt ZSB0byBnaXZlIHRpbWUgdG8gbG9naW4gaWYgdXNpbmcgc3lzdGVtIGJyb3dzZXIKICAgICAgICAg ICAgICAgICApCiAK ------=_Part_1312_2236077.1205522582024-- From john.stowers@gmail.com Fri Mar 14 23:36:40 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A6235750090 for ; Fri, 14 Mar 2008 23:36:40 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, TW_GT=0.077, TW_TK=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11735 hrs), (distance 13, link: (Google 2)), [209.85.200.174] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb8CB6OoAKtb for ; Fri, 14 Mar 2008 23:36:36 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by menubar.gnome.org (Postfix) with ESMTP id 6400775013D for ; Fri, 14 Mar 2008 23:36:36 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so4093833wfa.9 for ; Fri, 14 Mar 2008 16:36:34 -0700 (PDT) Received: by 10.142.148.7 with SMTP id v7mr5414480wfd.218.1205537794787; Fri, 14 Mar 2008 16:36:34 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Fri, 14 Mar 2008 16:36:34 -0700 (PDT) Message-ID: <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> Date: Sat, 15 Mar 2008 12:36:34 +1300 From: "John Stowers" To: "Chris Rivera" Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3837_30649762.1205537794778" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 23:36:40 -0000 ------=_Part_3837_30649762.1205537794778 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/3/15 Chris Rivera : > The current Facebook module forces the built-in browser to be used for > authentication. This should respect the 'Use Built in Web Browser' setting > in the properties dialog. Please CC me on replies. Hi Chris, Im not sure I like this change. The hardcoding of the built in web-browser in facebook is intentional - this is because if you make any facebook API calls with the (as yet unauthenticated token) it revokes that tokens validity, which means when the user finishes logging in, Conduits login token token request is denied. The alternative (which is what the system browser login does) is just to wait a fixed amount of time before checking if the user has logged in. This works OK, but its just a dirty hack - if the user takes too long to log in then Conduit just gives up, because any pending calls will invalidate the token (in the facebook case). The only solution that keeps all the code consistent between all dataproviders is to use the conduit web browser. As it happens I think this is actually a better solution, the user gets immediate feedback that the login they are being asked to perform is directly related to Conduit. I havent received any bug reports about Conduit crashing from the built in browser, so I am very tempted (for the next release) to make it the only way to log into websites. Thoughts? John > > Thanks, > Chris > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > > ------=_Part_3837_30649762.1205537794778 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

2008/3/15 Chris Rivera <chrismrivera@gmail.com>:
The current Facebook module forces the built-in browser to be used for authentication.  This should respect the 'Use Built in Web Browser' setting in the properties dialog.  Please CC me on replies.

Hi Chris,

Im not sure I like this change. The hardcoding of the built in web-browser in facebook is intentional - this is because if you make any facebook API calls with the (as yet unauthenticated token) it revokes that tokens validity, which means when the user finishes logging in, Conduits login token token request is denied.

The alternative (which is what the system browser login does) is just to wait a fixed amount of time before checking if the user has logged in. This works OK, but its just a dirty hack - if the user takes too long to log in then Conduit just gives up, because any pending calls will invalidate the token (in the facebook case).

The only solution that keeps all the code consistent between all dataproviders is to use the conduit web browser. As it happens I think this is actually a better solution, the user gets immediate feedback that the login they are being asked to perform is directly related to Conduit. I havent received any bug reports about Conduit crashing from the built in browser, so I am very tempted (for the next release) to make it the only way to log into websites.

Thoughts?

John



Thanks,
Chris

_______________________________________________
Conduit-list mailing list
Conduit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/conduit-list


------=_Part_3837_30649762.1205537794778-- From chrismrivera@gmail.com Sat Mar 15 03:04:26 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6F1B9750007 for ; Sat, 15 Mar 2008 03:04:26 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, TW_GT=0.077, TW_TK=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 3021 hrs), (distance 15, link: (Google 2)), [66.249.82.229] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrgmSctbfvrC for ; Sat, 15 Mar 2008 03:04:24 +0000 (GMT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by menubar.gnome.org (Postfix) with ESMTP id B26427500A5 for ; Sat, 15 Mar 2008 03:04:23 +0000 (GMT) Received: by wx-out-0506.google.com with SMTP id h26so4022242wxd.9 for ; Fri, 14 Mar 2008 20:04:21 -0700 (PDT) Received: by 10.150.192.7 with SMTP id p7mr6792560ybf.90.1205550261826; Fri, 14 Mar 2008 20:04:21 -0700 (PDT) Received: by 10.150.156.4 with HTTP; Fri, 14 Mar 2008 20:04:21 -0700 (PDT) Message-ID: <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> Date: Fri, 14 Mar 2008 23:04:21 -0400 From: "Chris Rivera" To: "John Stowers" Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2191_9645911.1205550261837" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2008 03:04:26 -0000 ------=_Part_2191_9645911.1205550261837 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Mar 14, 2008 at 7:36 PM, John Stowers wrote: > > > 2008/3/15 Chris Rivera : > > > The current Facebook module forces the built-in browser to be used for > > authentication. This should respect the 'Use Built in Web Browser' setting > > in the properties dialog. Please CC me on replies. > > > Hi Chris, > > Im not sure I like this change. The hardcoding of the built in web-browser > in facebook is intentional - this is because if you make any facebook API > calls with the (as yet unauthenticated token) it revokes that tokens > validity, which means when the user finishes logging in, Conduits login > token token request is denied. > This is similar to what happens with rememberthemilk. I was playing around with an RTM conduit module and ran into this same problem. > > The alternative (which is what the system browser login does) is just to > wait a fixed amount of time before checking if the user has logged in. This > works OK, but its just a dirty hack - if the user takes too long to log in > then Conduit just gives up, because any pending calls will invalidate the > token (in the facebook case). > I don't like the arbitrary timeout either. We don't know when the user grants or denies access when we use the system browser though. Does the built-in browser solve this problem? The only other (crappy) solution, that I can think of, is to run the system browser using a mechanism other than the webbrowser module so we can watch the process and then instruct the user to close the browser instance after they've granted or denied access. > > > The only solution that keeps all the code consistent between all > dataproviders is to use the conduit web browser. As it happens I think this > is actually a better solution, the user gets immediate feedback that the > login they are being asked to perform is directly related to Conduit. I > havent received any bug reports about Conduit crashing from the built in > browser, so I am very tempted (for the next release) to make it the only way > to log into websites. > > Thoughts? > I submitted the patch because it seems like there's an inconsistency between the built-in property and the browser behavior. I needed this option to work because gtkmozembed is segfaulting on opensuse11.0 alpha 2 with conduit trunk. It's segfaulting in libxpcom_core.so during gtkmozembed.MozEmbed(). Running python and doing this manually works fine though. I don't have a handle on what's going on yet. Chris ------=_Part_2191_9645911.1205550261837 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Mar 14, 2008 at 7:36 PM, John Stowers <john.stowers@gmail.com> wrote:


2008/3/15 Chris Rivera <chrismrivera@gmail.com>:

The current Facebook module forces the built-in browser to be used for authentication.  This should respect the 'Use Built in Web Browser' setting in the properties dialog.  Please CC me on replies.

Hi Chris,

Im not sure I like this change. The hardcoding of the built in web-browser in facebook is intentional - this is because if you make any facebook API calls with the (as yet unauthenticated token) it revokes that tokens validity, which means when the user finishes logging in, Conduits login token token request is denied.

This is similar to what happens with rememberthemilk.  I was playing around with an RTM conduit module and ran into this same problem.



The alternative (which is what the system browser login does) is just to wait a fixed amount of time before checking if the user has logged in. This works OK, but its just a dirty hack - if the user takes too long to log in then Conduit just gives up, because any pending calls will invalidate the token (in the facebook case).

I don't like the arbitrary timeout either.  We don't know when the user grants or denies access when we use the system browser though.  Does the built-in browser solve this problem?

The only other (crappy) solution, that I can think of, is to run the system browser using a mechanism other than the webbrowser module so we can watch the process and then instruct the user to close the browser instance after they've granted or denied access.
 


The only solution that keeps all the code consistent between all dataproviders is to use the conduit web browser. As it happens I think this is actually a better solution, the user gets immediate feedback that the login they are being asked to perform is directly related to Conduit. I havent received any bug reports about Conduit crashing from the built in browser, so I am very tempted (for the next release) to make it the only way to log into websites.

Thoughts?

I submitted the patch because it seems like there's an inconsistency between the built-in property and the browser behavior.

I needed this option to work because gtkmozembed is segfaulting on opensuse11.0 alpha 2 with conduit trunk.   It's segfaulting in libxpcom_core.so during gtkmozembed.MozEmbed().  Running python and doing this manually works fine though.  I don't have a handle on what's going on yet.

Chris

------=_Part_2191_9645911.1205550261837-- From john.stowers@gmail.com Sat Mar 15 03:25:11 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D4C21750099 for ; Sat, 15 Mar 2008 03:25:11 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, HTML_30_40=0.374, HTML_MESSAGE=0.001, TW_EV=0.077, TW_GT=0.077, TW_TK=0.077, TW_XD=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11773 hrs), (distance 13, link: (Google 2)), [209.85.200.171] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOmjo1TBSnYW for ; Sat, 15 Mar 2008 03:25:08 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by menubar.gnome.org (Postfix) with ESMTP id 1A77E7500AC for ; Sat, 15 Mar 2008 03:25:06 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so4162348wfa.9 for ; Fri, 14 Mar 2008 20:25:05 -0700 (PDT) Received: by 10.142.84.3 with SMTP id h3mr5467487wfb.34.1205551505389; Fri, 14 Mar 2008 20:25:05 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Fri, 14 Mar 2008 20:25:05 -0700 (PDT) Message-ID: <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> Date: Sat, 15 Mar 2008 16:25:05 +1300 From: "John Stowers" To: "Chris Rivera" Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4159_9360836.1205551505365" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2008 03:25:12 -0000 ------=_Part_4159_9360836.1205551505365 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Cris, thanks for the explanation, comments inline > Im not sure I like this change. The hardcoding of the built in web-browser > > in facebook is intentional - this is because if you make any facebook API > > calls with the (as yet unauthenticated token) it revokes that tokens > > validity, which means when the user finishes logging in, Conduits login > > token token request is denied. > > > > This is similar to what happens with rememberthemilk. I was playing > around with an RTM conduit module and ran into this same problem. > There is a RTM conduit module?? :-) > > > > > > > The alternative (which is what the system browser login does) is just to > > wait a fixed amount of time before checking if the user has logged in. This > > works OK, but its just a dirty hack - if the user takes too long to log in > > then Conduit just gives up, because any pending calls will invalidate the > > token (in the facebook case). > > > > I don't like the arbitrary timeout either. We don't know when the user > grants or denies access when we use the system browser though. Does the > built-in browser solve this problem? > The built in browser is at least detemininstic, i.e. It is guaranteed to block the caller until the user closes the tab that is being used to log in. This means that if authentication fails, it must have been because the user denied conduit access, and not because we called the web sites apis with an unauthenticated token > > The only other (crappy) solution, that I can think of, is to run the > system browser using a mechanism other than the webbrowser module so we can > watch the process and then instruct the user to close the browser instance > after they've granted or denied access. > There is no reliable way to create a blocking webbrowser call. I looked for a really really long time into how to do this sensibly, to no avail. webbrowser and xdg-open and gnomevfs all behave differently depending on whether 1) The browser is already running somewhere 2) The user has selected to 'always open new links in tabs' 3) The phase of the moon. I really hope we can get gtkmoxembed to stop segfaulting, the built in login browser is a lot more pleasant experience! > > > > > The only solution that keeps all the code consistent between all > > dataproviders is to use the conduit web browser. As it happens I think this > > is actually a better solution, the user gets immediate feedback that the > > login they are being asked to perform is directly related to Conduit. I > > havent received any bug reports about Conduit crashing from the built in > > browser, so I am very tempted (for the next release) to make it the only way > > to log into websites. > > > > Thoughts? > > > > I submitted the patch because it seems like there's an inconsistency > between the built-in property and the browser behavior. > True. Im not opposed to it completely, it just reminded me of how frustrating the whole webbrowers mess was! > > > I needed this option to work because gtkmozembed is segfaulting on > opensuse11.0 alpha 2 with conduit trunk. It's segfaulting in > libxpcom_core.so during gtkmozembed.MozEmbed(). Running python and doing > this manually works fine though. I don't have a handle on what's going on > yet. > Have you checked the conduit/conduit shell script (i.e. not conduit/conduit.real python code) to check that it finds the run-mozilla script? see the line FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1` is that the correct path on opensuse for ff libs? The TestWebBrowser dataprovider is useful for testing the built in browser Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed this problem, no more yucky wrapper script needed! Let me know if this helps John > > Chris > > ------=_Part_4159_9360836.1205551505365 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Cris, thanks for the explanation, comments inline
 
Im not sure I like this change. The hardcoding of the built in web-browser in facebook is intentional - this is because if you make any facebook API calls with the (as yet unauthenticated token) it revokes that tokens validity, which means when the user finishes logging in, Conduits login token token request is denied.

This is similar to what happens with rememberthemilk.  I was playing around with an RTM conduit module and ran into this same problem.

There is a RTM conduit module?? :-)
 




The alternative (which is what the system browser login does) is just to wait a fixed amount of time before checking if the user has logged in. This works OK, but its just a dirty hack - if the user takes too long to log in then Conduit just gives up, because any pending calls will invalidate the token (in the facebook case).

I don't like the arbitrary timeout either.  We don't know when the user grants or denies access when we use the system browser though.  Does the built-in browser solve this problem?

The built in browser is at least detemininstic, i.e. It is guaranteed to block the caller until the user closes the tab that is being used to log in. This means that if authentication fails, it must have been because the user denied conduit access, and not because we called the web sites apis with an unauthenticated token



The only other (crappy) solution, that I can think of, is to run the system browser using a mechanism other than the webbrowser module so we can watch the process and then instruct the user to close the browser instance after they've granted or denied access.

There is no reliable way to create a blocking webbrowser call. I looked for a really really long time into how to do this sensibly, to no avail. webbrowser and xdg-open and gnomevfs all behave differently depending on whether
1) The browser is already running somewhere
2) The user has selected to 'always open new links in tabs'
3) The phase of the moon.

I really hope we can get gtkmoxembed to stop segfaulting, the built in login browser is a lot more pleasant experience!




The only solution that keeps all the code consistent between all dataproviders is to use the conduit web browser. As it happens I think this is actually a better solution, the user gets immediate feedback that the login they are being asked to perform is directly related to Conduit. I havent received any bug reports about Conduit crashing from the built in browser, so I am very tempted (for the next release) to make it the only way to log into websites.

Thoughts?

I submitted the patch because it seems like there's an inconsistency between the built-in property and the browser behavior.

True.  Im not opposed to it completely, it just reminded me of how frustrating the whole webbrowers mess was!


I needed this option to work because gtkmozembed is segfaulting on opensuse11.0 alpha 2 with conduit trunk.   It's segfaulting in libxpcom_core.so during gtkmozembed.MozEmbed().  Running python and doing this manually works fine though.  I don't have a handle on what's going on yet. 

Have you checked the conduit/conduit shell script (i.e. not conduit/conduit.real python code) to check that it finds the run-mozilla script?

see the line

FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1`

is that the correct path on opensuse for ff libs?

The TestWebBrowser dataprovider is useful for testing the built in browser

Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed this problem, no more yucky wrapper script needed!

Let me know if this helps

John



Chris


------=_Part_4159_9360836.1205551505365-- From airmind@gmail.com Sat Mar 15 04:11:15 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7787D750082 for ; Sat, 15 Mar 2008 04:11:15 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=2 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, TW_EV=0.077, TW_GT=0.077, TW_TK=0.077, TW_XD=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 2238 hrs), (distance 15, link: (Google 2)), [64.233.178.244] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIHa9xU99PTK for ; Sat, 15 Mar 2008 04:11:13 +0000 (GMT) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.244]) by menubar.gnome.org (Postfix) with ESMTP id 10E02750007 for ; Sat, 15 Mar 2008 04:11:12 +0000 (GMT) Received: by hs-out-0708.google.com with SMTP id l65so3275087hsc.15 for ; Fri, 14 Mar 2008 21:11:11 -0700 (PDT) Received: by 10.150.156.9 with SMTP id d9mr6829426ybe.116.1205554271276; Fri, 14 Mar 2008 21:11:11 -0700 (PDT) Received: by 10.150.134.12 with HTTP; Fri, 14 Mar 2008 21:11:11 -0700 (PDT) Message-ID: <48f4838d0803142111p6e508491t11ba820be3c4de47@mail.gmail.com> Date: Sat, 15 Mar 2008 01:11:11 -0300 From: Alexandre To: "John Stowers" Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2065_20362742.1205554271292" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> Cc: conduit-list@gnome.org, Chris Rivera X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2008 04:11:15 -0000 ------=_Part_2065_20362742.1205554271292 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I like the idea of the external browser, because sometimes the user is already logged in, and only has to authorize or something else. This happen= s on Flickr for instance. The only other (crappy) solution, that I can think of, is to run the system > > browser using a mechanism other than the webbrowser module so we can wa= tch > > the process and then instruct the user to close the browser instance af= ter > > they've granted or denied access. > > > > There is no reliable way to create a blocking webbrowser call. I looked > for a really really long time into how to do this sensibly, to no avail. > webbrowser and xdg-open and gnomevfs all behave differently depending on > whether > 1) The browser is already running somewhere > 2) The user has selected to 'always open new links in tabs' > 3) The phase of the moon. > > I really hope we can get gtkmoxembed to stop segfaulting, the built in > login browser is a lot more pleasant experience! > This is just an idea I got from MusicBrainz. It runs a very small server on some port (probably an http server), opens the user browser with a page and the port as a parameter, then that port is called from within that page. For this to work in our situation, it could go into a page hosted in the Conduit server, or a page served locally from Conduit, showing a message to close that page after authentication and a frame with the Facebook login page. Some javascript code could contact the port when the page is closed t= o tell Conduit that authentication is over. There are drawbacks, but could be a workaround. Maybe security could be an issue here, because this page could be hijacked and the login information stolen by someone else. What do you think? --=20 Alexandre Rosenfeld EngComp 06 - USP S=E3o Carlos ------=_Part_2065_20362742.1205554271292 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I like the idea of the external browser, because sometimes the user is alre= ady logged in, and only has to authorize or something else. This happens on= Flickr for instance.

The only ot= her (crappy) solution, that I can think of, is to run the system browser us= ing a mechanism other than the webbrowser module so we can watch the proces= s and then instruct the user to close the browser instance after they'v= e granted or denied access.

There is no reliable way to create a bloc= king webbrowser call. I looked for a really really long time into how to do= this sensibly, to no avail. webbrowser and xdg-open and gnomevfs all behav= e differently depending on whether
1) The browser is already running somewhere
2) The user has selected to = 'always open new links in tabs'
3) The phase of the moon.
I really hope we can get gtkmoxembed to stop segfaulting, the built in log= in browser is a lot more pleasant experience!

This is just an idea I got from MusicBra= inz. It runs a very small server on some port (probably an http server), opens the user browser with a page and the port as a parameter, then that port is called from within that page.
For this to work in our situation, it could go into a page hosted in the Conduit server, or a page served locally from Conduit, showing a message to close that page after authentication and a frame with the Facebook login page. Some javascript code could contact the port when the page is closed to tell Conduit that authentication is over. There are drawbacks, but could be a workaround.
Maybe security could be an issue here, because this page could be hijacked = and the login information stolen by someone else.
What do you think?
=
--
Alexandre Rosenfeld

EngComp 06 - USP S=E3o Carlos ------=_Part_2065_20362742.1205554271292-- From john.stowers@gmail.com Sat Mar 15 04:23:28 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5A9EA7500A5 for ; Sat, 15 Mar 2008 04:23:28 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=2 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, TW_EV=0.077, TW_GT=0.077, TW_TK=0.077, TW_XD=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11783 hrs), (distance 12, link: (Google 2)), [209.85.200.169] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FdoNZIM3BWP for ; Sat, 15 Mar 2008 04:23:24 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by menubar.gnome.org (Postfix) with ESMTP id 357D0750007 for ; Sat, 15 Mar 2008 04:23:23 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so4173112wfa.9 for ; Fri, 14 Mar 2008 21:23:22 -0700 (PDT) Received: by 10.142.172.12 with SMTP id u12mr5473718wfe.19.1205555002674; Fri, 14 Mar 2008 21:23:22 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Fri, 14 Mar 2008 21:23:22 -0700 (PDT) Message-ID: <7e40b04b0803142123n68f4887s449f76a94bfbcd4b@mail.gmail.com> Date: Sat, 15 Mar 2008 17:23:22 +1300 From: "John Stowers" To: Alexandre Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <48f4838d0803142111p6e508491t11ba820be3c4de47@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4308_26082298.1205555002680" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> <48f4838d0803142111p6e508491t11ba820be3c4de47@mail.gmail.com> Cc: conduit-list@gnome.org, Chris Rivera X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2008 04:23:28 -0000 ------=_Part_4308_26082298.1205555002680 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, Mar 15, 2008 at 5:11 PM, Alexandre wrote: > I like the idea of the external browser, because sometimes the user is > already logged in, and only has to authorize or something else. This happ= ens > on Flickr for instance. I don't agree. Let me explain. There are basically two types of sites, ones that make you log in all the time (box.net, facebook), and ones that make you log in once (Flickr). For those sites that make you log in once, I dont think its too much effort to ask the user to log in again, after all, its only once. If sites make you log in all the time, then I am interested in making that experience enjoyable and easy. Its only possible to do that consistently with a built in browser approach. So in the end its a compromise. I think the best compromise is to make the common case the best, with the smallest amount of code. Thoughts? John > > The only other (crappy) solution, that I can think of, is to run the > > > system browser using a mechanism other than the webbrowser module so = we can > > > watch the process and then instruct the user to close the browser ins= tance > > > after they've granted or denied access. > > > > > > > There is no reliable way to create a blocking webbrowser call. I looked > > for a really really long time into how to do this sensibly, to no avail= . > > webbrowser and xdg-open and gnomevfs all behave differently depending o= n > > whether > > 1) The browser is already running somewhere > > 2) The user has selected to 'always open new links in tabs' > > 3) The phase of the moon. > > > > I really hope we can get gtkmoxembed to stop segfaulting, the built in > > login browser is a lot more pleasant experience! > > > > This is just an idea I got from MusicBrainz. It runs a very small server > on some port (probably an http server), opens the user browser with a pag= e > and the port as a parameter, then that port is called from within that pa= ge. > > For this to work in our situation, it could go into a page hosted in the > Conduit server, or a page served locally from Conduit, showing a message = to > close that page after authentication and a frame with the Facebook login > page. Some javascript code could contact the port when the page is closed= to > tell Conduit that authentication is over. There are drawbacks, but could = be > a workaround. > Maybe security could be an issue here, because this page could be hijacke= d > and the login information stolen by someone else. > What do you think? > > -- > Alexandre Rosenfeld > > EngComp 06 - USP S=E3o Carlos > ------=_Part_4308_26082298.1205555002680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Sat, Mar 15, 2008 at 5:11 PM, Alexand= re <airmind@gmail.com> wrote= :
I like the idea of the external browser, because sometimes the user is alre= ady logged in, and only has to authorize or something else. This happens on= Flickr for instance.

I don't agree. Let me explai= n. There are basically two types of sites, ones that make you log in all th= e time (box.net, facebook), and ones that ma= ke you log in once (Flickr).

For those sites that make you log in once, I dont think its too much ef= fort to ask the user to log in again, after all, its only once.

If s= ites make you log in all the time, then I am interested in making that expe= rience enjoyable and easy. Its only possible to do that consistently with a= built in browser approach.

So in the end its a compromise. I think the best compromise is to make = the common case the best, with the smallest amount of code.

Thoughts= ?

John




The only other (crappy) solu= tion, that I can think of, is to run the system browser using a mechanism o= ther than the webbrowser module so we can watch the process and then instru= ct the user to close the browser instance after they've granted or deni= ed access.

There is no reliable way to create a bloc= king webbrowser call. I looked for a really really long time into how to do= this sensibly, to no avail. webbrowser and xdg-open and gnomevfs all behav= e differently depending on whether
1) The browser is already running somewhere
2) The user has selected to = 'always open new links in tabs'
3) The phase of the moon.
I really hope we can get gtkmoxembed to stop segfaulting, the built in log= in browser is a lot more pleasant experience!

This is just an idea I got from MusicBrainz. It runs a very small server on some port (probably an http server), opens the user browser with a page and the port as a parameter, then that port is called from within that page.
For this to work in our situation, it could go into a page hosted in the Conduit server, or a page served locally from Conduit, showing a message to close that page after authentication and a frame with the Facebook login page. Some javascript code could contact the port when the page is closed to tell Conduit that authentication is over. There are drawbacks, but could be a workaround.
Maybe security could be an issue here, because this page could be hijacked = and the login information stolen by someone else.
What do you think?
=
--
Alexandre Rosenfeld

EngComp 06 - USP S=E3o Carlos

------=_Part_4308_26082298.1205555002680-- From chrismrivera@gmail.com Mon Mar 17 19:18:54 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F21E87501DE for ; Mon, 17 Mar 2008 19:18:53 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, TW_GT=0.077, TW_TK=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11011 hrs), (distance 13, link: (Google 2)), [209.85.142.185] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg+20z7Qg+XC for ; Mon, 17 Mar 2008 19:18:49 +0000 (GMT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by menubar.gnome.org (Postfix) with ESMTP id 8590A75023C for ; Mon, 17 Mar 2008 19:18:46 +0000 (GMT) Received: by ti-out-0910.google.com with SMTP id b8so2373451tic.1 for ; Mon, 17 Mar 2008 12:18:37 -0700 (PDT) Received: by 10.150.135.2 with SMTP id i2mr331704ybd.197.1205781515784; Mon, 17 Mar 2008 12:18:35 -0700 (PDT) Received: by 10.150.156.4 with HTTP; Mon, 17 Mar 2008 12:18:35 -0700 (PDT) Message-ID: <5f84803c0803171218q4f342aeh41495446b496c2ee@mail.gmail.com> Date: Mon, 17 Mar 2008 15:18:35 -0400 From: "Chris Rivera" To: "John Stowers" Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7759_12919051.1205781515766" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 19:18:54 -0000 ------=_Part_7759_12919051.1205781515766 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Mar 14, 2008 at 11:25 PM, John Stowers wrote: > Hi Cris, thanks for the explanation, comments inline > > > > Im not sure I like this change. The hardcoding of the built in > > > web-browser in facebook is intentional - this is because if you make any > > > facebook API calls with the (as yet unauthenticated token) it revokes that > > > tokens validity, which means when the user finishes logging in, Conduits > > > login token token request is denied. > > > > > > > This is similar to what happens with rememberthemilk. I was playing > > around with an RTM conduit module and ran into this same problem. > > > > There is a RTM conduit module?? :-) > I've been playing around with one. I'm not quite sure how to map the tasks to conduit data types. RTM is set of lists that contains tasks. Each task can have several notes about the task. Each task also has scheduling information. Suggestions? > > > > > > I needed this option to work because gtkmozembed is segfaulting on > > opensuse11.0 alpha 2 with conduit trunk. It's segfaulting in > > libxpcom_core.so during gtkmozembed.MozEmbed(). Running python and > > doing this manually works fine though. I don't have a handle on what's > > going on yet. > > > > Have you checked the conduit/conduit shell script (i.e. not > conduit/conduit.real python code) to check that it finds the run-mozilla > script? > > see the line > > FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1` > > is that the correct path on opensuse for ff libs? > > The TestWebBrowser dataprovider is useful for testing the built in browser > > Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed > this problem, no more yucky wrapper script needed! > > Let me know if this helps > The conduit shell script is working correctly. If I run run-mozilla.sh and just run CheckGtkMozEmbed.py I get the same crash. If I run CheckGtkMozEmbed.py without run-mozilla.sh it works fine. Chris ------=_Part_7759_12919051.1205781515766 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Mar 14, 2008 at 11:25 PM, John Stowers <john.stowers@gmail.com> wrote:
Hi Cris, thanks for the explanation, comments inline
 
Im not sure I like this change. The hardcoding of the built in web-browser in facebook is intentional - this is because if you make any facebook API calls with the (as yet unauthenticated token) it revokes that tokens validity, which means when the user finishes logging in, Conduits login token token request is denied.

This is similar to what happens with rememberthemilk.  I was playing around with an RTM conduit module and ran into this same problem.

There is a RTM conduit module?? :-)

I've been playing around with one.  I'm not quite sure how to map the tasks to conduit data types.  RTM is set of lists that contains tasks.  Each task can have several notes about the task.  Each task also has scheduling information.  Suggestions?



I needed this option to work because gtkmozembed is segfaulting on opensuse11.0 alpha 2 with conduit trunk.   It's segfaulting in libxpcom_core.so during gtkmozembed.MozEmbed().  Running python and doing this manually works fine though.  I don't have a handle on what's going on yet. 

Have you checked the conduit/conduit shell script (i.e. not conduit/conduit.real python code) to check that it finds the run-mozilla script?

see the line

FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1`

is that the correct path on opensuse for ff libs?

The TestWebBrowser dataprovider is useful for testing the built in browser

Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed this problem, no more yucky wrapper script needed!

Let me know if this helps

The conduit shell script is working correctly.  If I run run-mozilla.sh and just run CheckGtkMozEmbed.py I get the same crash.  If I run CheckGtkMozEmbed.py without run-mozilla.sh it works fine.

Chris

------=_Part_7759_12919051.1205781515766-- From john.stowers@gmail.com Mon Mar 17 19:32:43 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B8267750183 for ; Mon, 17 Mar 2008 19:32:43 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, TW_GT=0.077, TW_TK=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 484 hrs), (distance 13, link: (Google 2)), [209.85.200.168] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plkBMM9jTrni for ; Mon, 17 Mar 2008 19:32:39 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by menubar.gnome.org (Postfix) with ESMTP id 04FEB750199 for ; Mon, 17 Mar 2008 19:32:38 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so5314629wfa.9 for ; Mon, 17 Mar 2008 12:32:37 -0700 (PDT) Received: by 10.142.84.3 with SMTP id h3mr604004wfb.113.1205782357118; Mon, 17 Mar 2008 12:32:37 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Mon, 17 Mar 2008 12:32:37 -0700 (PDT) Message-ID: <7e40b04b0803171232iacd56d8n733738c675b2e3a6@mail.gmail.com> Date: Tue, 18 Mar 2008 08:32:37 +1300 From: "John Stowers" To: "Chris Rivera" Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <5f84803c0803171218q4f342aeh41495446b496c2ee@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14147_9626421.1205782357110" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> <5f84803c0803171218q4f342aeh41495446b496c2ee@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 19:32:44 -0000 ------=_Part_14147_9626421.1205782357110 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Mar 18, 2008 at 8:18 AM, Chris Rivera wrote: > On Fri, Mar 14, 2008 at 11:25 PM, John Stowers > wrote: > > > Hi Cris, thanks for the explanation, comments inline > > > > > > > Im not sure I like this change. The hardcoding of the built in > > > > web-browser in facebook is intentional - this is because if you make any > > > > facebook API calls with the (as yet unauthenticated token) it revokes that > > > > tokens validity, which means when the user finishes logging in, Conduits > > > > login token token request is denied. > > > > > > > > > > This is similar to what happens with rememberthemilk. I was playing > > > around with an RTM conduit module and ran into this same problem. > > > > > > > There is a RTM conduit module?? :-) > > > > I've been playing around with one. I'm not quite sure how to map the > tasks to conduit data types. RTM is set of lists that contains tasks. Each > task can have several notes about the task. Each task also has scheduling > information. Suggestions? > This sounds like how backpackit.com works. In that case I just create a page (called Conduit by default, configurable, if it doesn't exist), and put the notes on that page. Its not perfect, but backpackit.com is not optimal, the web interface doesnt even record the modification times for notes when they are edited from the web. > > > > > > > > > I needed this option to work because gtkmozembed is segfaulting on > > > opensuse11.0 alpha 2 with conduit trunk. It's segfaulting in > > > libxpcom_core.so during gtkmozembed.MozEmbed(). Running python and > > > doing this manually works fine though. I don't have a handle on what's > > > going on yet. > > > > > > > Have you checked the conduit/conduit shell script (i.e. not > > conduit/conduit.real python code) to check that it finds the run-mozilla > > script? > > > > see the line > > > > FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1` > > > > is that the correct path on opensuse for ff libs? > > > > The TestWebBrowser dataprovider is useful for testing the built in > > browser > > > > Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed > > this problem, no more yucky wrapper script needed! > > > > Let me know if this helps > > > > The conduit shell script is working correctly. If I run run-mozilla.shand just run > CheckGtkMozEmbed.py I get the same crash. If I run CheckGtkMozEmbed.pywithout > run-mozilla.sh it works fine. > Hmm, thats a weird combination of things working/not working. The only time I have seen something similar to what you describe is when I had ff3 and ff2 both installed and it would find the wrong run-mozilla.sh script, or something like that, I dont remember exactly. Im sorry I cant be of more help tracking this down. If conduit works on your distribution without the wrapper script then the packagers are welcome to remove the wrapper, like I am going to recommend is done in ubuntu 8.04conduit package -it seems to be no longer needed with ff3/gecko 1.9 John > > > Chris > > ------=_Part_14147_9626421.1205782357110 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Tue, Mar 18, 2008 at 8:18 AM, Chris Rivera <chrismrivera@gmail.com> wrote:
On Fri, Mar 14, 2008 at 11:25 PM, John Stowers <john.stowers@gmail.com> wrote:
Hi Cris, thanks for the explanation, comments inline
 
Im not sure I like this change. The hardcoding of the built in web-browser in facebook is intentional - this is because if you make any facebook API calls with the (as yet unauthenticated token) it revokes that tokens validity, which means when the user finishes logging in, Conduits login token token request is denied.

This is similar to what happens with rememberthemilk.  I was playing around with an RTM conduit module and ran into this same problem.

There is a RTM conduit module?? :-)

I've been playing around with one.  I'm not quite sure how to map the tasks to conduit data types.  RTM is set of lists that contains tasks.  Each task can have several notes about the task.  Each task also has scheduling information.  Suggestions?

This sounds like how backpackit.com works. In that case I just create a page (called Conduit by default, configurable, if it doesn't exist), and put the notes on that page. Its not perfect, but backpackit.com is not optimal, the web interface doesnt even record the modification times for notes when they are edited from the web.





I needed this option to work because gtkmozembed is segfaulting on opensuse11.0 alpha 2 with conduit trunk.   It's segfaulting in libxpcom_core.so during gtkmozembed.MozEmbed().  Running python and doing this manually works fine though.  I don't have a handle on what's going on yet. 

Have you checked the conduit/conduit shell script (i.e. not conduit/conduit.real python code) to check that it finds the run-mozilla script?

see the line

FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1`

is that the correct path on opensuse for ff libs?

The TestWebBrowser dataprovider is useful for testing the built in browser

Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed this problem, no more yucky wrapper script needed!

Let me know if this helps

The conduit shell script is working correctly.  If I run run-mozilla.sh and just run CheckGtkMozEmbed.py I get the same crash.  If I run CheckGtkMozEmbed.py without run-mozilla.sh it works fine.

Hmm, thats a weird combination of things working/not working. The only time I have seen something similar to what you describe is when I had ff3 and ff2 both installed and it would find the wrong run-mozilla.sh script, or something like that, I dont remember exactly.

Im sorry I cant be of more help tracking this down. If conduit works on your distribution without the wrapper script then the packagers are welcome to remove the wrapper, like I am going to recommend is done in ubuntu 8.04 conduit package -it seems to be no longer needed with ff3/gecko 1.9

John
 
 


Chris


------=_Part_14147_9626421.1205782357110-- From john.stowers@gmail.com Mon Mar 17 20:54:21 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 10AF1750006 for ; Mon, 17 Mar 2008 20:54:21 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, TW_GT=0.077, TW_TK=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 10610 hrs), (distance 16, link: (Google 2)), [66.249.90.183] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkmVgWXw1GI5 for ; Mon, 17 Mar 2008 20:54:17 +0000 (GMT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.183]) by menubar.gnome.org (Postfix) with ESMTP id E3430750199 for ; Mon, 17 Mar 2008 20:54:16 +0000 (GMT) Received: by ik-out-1112.google.com with SMTP id b35so1862026ika.7 for ; Mon, 17 Mar 2008 13:54:14 -0700 (PDT) Received: by 10.142.126.17 with SMTP id y17mr708919wfc.170.1205787247493; Mon, 17 Mar 2008 13:54:07 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Mon, 17 Mar 2008 13:54:07 -0700 (PDT) Message-ID: <7e40b04b0803171354n2b8ef424ga03f12ca2ad309f6@mail.gmail.com> Date: Tue, 18 Mar 2008 09:54:07 +1300 From: "John Stowers" To: "Chris Rivera" Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <7e40b04b0803171232iacd56d8n733738c675b2e3a6@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14629_16200876.1205787247489" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> <5f84803c0803171218q4f342aeh41495446b496c2ee@mail.gmail.com> <7e40b04b0803171232iacd56d8n733738c675b2e3a6@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 20:54:21 -0000 ------=_Part_14629_16200876.1205787247489 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Mar 18, 2008 at 8:32 AM, John Stowers wrote: > > > On Tue, Mar 18, 2008 at 8:18 AM, Chris Rivera > wrote: > > > On Fri, Mar 14, 2008 at 11:25 PM, John Stowers > > wrote: > > > > > > > Hi Cris, thanks for the explanation, comments inline > > > > > > > > > > Im not sure I like this change. The hardcoding of the built in > > > > > web-browser in facebook is intentional - this is because if you make any > > > > > facebook API calls with the (as yet unauthenticated token) it revokes that > > > > > tokens validity, which means when the user finishes logging in, Conduits > > > > > login token token request is denied. > > > > > > > > > > > > > This is similar to what happens with rememberthemilk. I was playing > > > > around with an RTM conduit module and ran into this same problem. > > > > > > > > > > There is a RTM conduit module?? :-) > > > > > > > I've been playing around with one. I'm not quite sure how to map the > > tasks to conduit data types. RTM is set of lists that contains tasks. Each > > task can have several notes about the task. Each task also has scheduling > > information. Suggestions? > > > > This sounds like how backpackit.com works. In that case I just create a > page (called Conduit by default, configurable, if it doesn't exist), and put > the notes on that page. Its not perfect, but backpackit.com is not > optimal, the web interface doesnt even record the modification times for > notes when they are edited from the web. > Oh yeah I forgot to mention. Please feel free to post your work to the list. I have a few people who are looking for RTM support, and while I dont have the time to implement it myself, I would definately give you a hand. Regarding types, its a difficult one. Whats your primary use case? If its notes then I would take an approach like the backpackit.com one, create a 'dummy' task, specially and configurably named, just for the purposes of attaching notes. For task sync I guess you could then go ahead and match them 1:1. If we are talking about evolution tasks then you could map the summary to the task title, and the task contents to a single note attached to that task. Using the built in data types is a simple place to start. It might be necessary to add some conveninece funtions to Event to make it easier to set/get task like info (completion, summary, etc) John > > > > > > > > > > > > > > > > > > > > > > > > I needed this option to work because gtkmozembed is segfaulting on > > > > opensuse11.0 alpha 2 with conduit trunk. It's segfaulting in > > > > libxpcom_core.so during gtkmozembed.MozEmbed(). Running python and > > > > doing this manually works fine though. I don't have a handle on what's > > > > going on yet. > > > > > > > > > > Have you checked the conduit/conduit shell script (i.e. not > > > conduit/conduit.real python code) to check that it finds the run-mozilla > > > script? > > > > > > see the line > > > > > > FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1` > > > > > > is that the correct path on opensuse for ff libs? > > > > > > The TestWebBrowser dataprovider is useful for testing the built in > > > browser > > > > > > Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed > > > this problem, no more yucky wrapper script needed! > > > > > > Let me know if this helps > > > > > > > > > > The conduit shell script is working correctly. If I run run-mozilla.shand just run > > CheckGtkMozEmbed.py I get the same crash. If I run CheckGtkMozEmbed.pywithout > > run-mozilla.sh it works fine. > > > > Hmm, thats a weird combination of things working/not working. The only > time I have seen something similar to what you describe is when I had ff3 > and ff2 both installed and it would find the wrong run-mozilla.sh script, > or something like that, I dont remember exactly. > > Im sorry I cant be of more help tracking this down. If conduit works on > your distribution without the wrapper script then the packagers are welcome > to remove the wrapper, like I am going to recommend is done in ubuntu 8.04conduit package -it seems to be no longer needed with ff3/gecko > 1.9 > > John > > > > > > > > > Chris > > > > > > > ------=_Part_14629_16200876.1205787247489 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Tue, Mar 18, 2008 at 8:32 AM, John Stowers <john.stowers@gmail.com> wrote:


On Tue, Mar 18, 2008 at 8:18 AM, Chris Rivera <chrismrivera@gmail.com> wrote:
On Fri, Mar 14, 2008 at 11:25 PM, John Stowers <john.stowers@gmail.com> wrote:
 
Hi Cris, thanks for the explanation, comments inline
 
Im not sure I like this change. The hardcoding of the built in web-browser in facebook is intentional - this is because if you make any facebook API calls with the (as yet unauthenticated token) it revokes that tokens validity, which means when the user finishes logging in, Conduits login token token request is denied.

This is similar to what happens with rememberthemilk.  I was playing around with an RTM conduit module and ran into this same problem.

There is a RTM conduit module?? :-)

I've been playing around with one.  I'm not quite sure how to map the tasks to conduit data types.  RTM is set of lists that contains tasks.  Each task can have several notes about the task.  Each task also has scheduling information.  Suggestions?

This sounds like how backpackit.com works. In that case I just create a page (called Conduit by default, configurable, if it doesn't exist), and put the notes on that page. Its not perfect, but backpackit.com is not optimal, the web interface doesnt even record the modification times for notes when they are edited from the web.

Oh yeah I forgot to mention. Please feel free to post your work to the list. I have a few people who are looking for RTM support, and while I dont have the time to implement it myself, I would definately give you a hand.
 
Regarding types, its a difficult one. Whats your primary use case? If its notes then I would take an approach like the backpackit.com one, create a 'dummy' task, specially and configurably named, just for the purposes of attaching notes.
 
For task sync I guess you could then go ahead and match them 1:1. If we are talking about evolution tasks then you could map the summary to the task title, and the task contents to a single note attached to that task.
 
Using the built in data types is a simple place to start. It might be necessary to add some conveninece funtions to Event to make it easier to set/get task like info (completion, summary, etc)
 
John

 


 

 



I needed this option to work because gtkmozembed is segfaulting on opensuse11.0 alpha 2 with conduit trunk.   It's segfaulting in libxpcom_core.so during gtkmozembed.MozEmbed().  Running python and doing this manually works fine though.  I don't have a handle on what's going on yet. 

Have you checked the conduit/conduit shell script (i.e. not conduit/conduit.real python code) to check that it finds the run-mozilla script?

see the line

FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1`

is that the correct path on opensuse for ff libs?

The TestWebBrowser dataprovider is useful for testing the built in browser

Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed this problem, no more yucky wrapper script needed!

Let me know if this helps
 

The conduit shell script is working correctly.  If I run run-mozilla.sh and just run CheckGtkMozEmbed.py I get the same crash.  If I run CheckGtkMozEmbed.py without run-mozilla.sh it works fine.

Hmm, thats a weird combination of things working/not working. The only time I have seen something similar to what you describe is when I had ff3 and ff2 both installed and it would find the wrong run-mozilla.sh script, or something like that, I dont remember exactly.

Im sorry I cant be of more help tracking this down. If conduit works on your distribution without the wrapper script then the packagers are welcome to remove the wrapper, like I am going to recommend is done in ubuntu 8.04 conduit package -it seems to be no longer needed with ff3/gecko 1.9

John
 
 


Chris
 



------=_Part_14629_16200876.1205787247489-- From creeva@gmail.com Tue Mar 18 13:05:59 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 29C3D75011E for ; Tue, 18 Mar 2008 13:05:59 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.611 X-Spam-Level: X-Spam-Status: No, score=0.611 tagged_above=-999 required=2 tests=[BAYES_40=-0.185, HTML_00_10=0.795, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 659 hrs), (distance 12, link: (Google 2)), [209.85.200.175] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3d5kqhM7N3V for ; Tue, 18 Mar 2008 13:05:57 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by menubar.gnome.org (Postfix) with ESMTP id A8F4675013E for ; Tue, 18 Mar 2008 13:05:57 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so5679893wfa.9 for ; Tue, 18 Mar 2008 06:05:56 -0700 (PDT) Received: by 10.142.141.21 with SMTP id o21mr872199wfd.56.1205845556160; Tue, 18 Mar 2008 06:05:56 -0700 (PDT) Received: by 10.70.116.5 with HTTP; Tue, 18 Mar 2008 06:05:56 -0700 (PDT) Message-ID: <2510ddab0803180605i77a336c1i7821cb6f5516d11d@mail.gmail.com> Date: Tue, 18 Mar 2008 09:05:56 -0400 From: "Brent Gueth" To: Conduit Subject: When is the documentation being commited to the SVN? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6024_31349307.1205845556069" X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 13:05:59 -0000 ------=_Part_6024_31349307.1205845556069 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I can do some more work on what I actually know (or figured out on my own which may still be wrong sometimes as we've seen) probably tomorrow night - in a real squeeze I can try to get some done tonight. ------=_Part_6024_31349307.1205845556069 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I can do some more work on what I actually know (or figured out on my own which may still be wrong sometimes as we've seen) probably tomorrow night - in a real squeeze I can try to get some done tonight.
------=_Part_6024_31349307.1205845556069-- From john.stowers@gmail.com Tue Mar 18 13:17:56 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6E31E750081 for ; Tue, 18 Mar 2008 13:17:56 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 661 hrs), (distance 12, link: (Google 2)), [209.85.200.169] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xZHHRPYQmEA for ; Tue, 18 Mar 2008 13:17:50 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by menubar.gnome.org (Postfix) with ESMTP id BCC4475004C for ; Tue, 18 Mar 2008 13:17:50 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so5684236wfa.9 for ; Tue, 18 Mar 2008 06:17:49 -0700 (PDT) Received: by 10.142.229.4 with SMTP id b4mr888213wfh.118.1205846269189; Tue, 18 Mar 2008 06:17:49 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Tue, 18 Mar 2008 06:17:49 -0700 (PDT) Message-ID: <7e40b04b0803180617l72fb0085uba6dfddd20ff350b@mail.gmail.com> Date: Wed, 19 Mar 2008 02:17:49 +1300 From: "John Stowers" To: "Brent Gueth" Subject: Re: When is the documentation being commited to the SVN? In-Reply-To: <2510ddab0803180605i77a336c1i7821cb6f5516d11d@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17831_12012379.1205846269161" References: <2510ddab0803180605i77a336c1i7821cb6f5516d11d@mail.gmail.com> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 13:17:56 -0000 ------=_Part_17831_12012379.1205846269161 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/3/19 Brent Gueth : > I can do some more work on what I actually know (or figured out on my own > which may still be wrong sometimes as we've seen) probably tomorrow night - > in a real squeeze I can try to get some done tonight. I committed some more tonight, as you probbably saw, highlighting the network sync. I really wanted to get a release out ASAP, and am happy to commit more docs as they get converted to docbook (it takes time). I think its important to get things like conflict resolution documented first, and then the data provider specific docs a bit later. As I have said, converting from the wiki (render as docbook), to the gnome docbook format takes time and help is appreciated. John > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > > ------=_Part_17831_12012379.1205846269161 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

2008/3/19 Brent Gueth <creeva@gmail.com>:
I can do some more work on what I actually know (or figured out on my own which may still be wrong sometimes as we've seen) probably tomorrow night - in a real squeeze I can try to get some done tonight.

I committed some more tonight, as you probbably saw, highlighting the network sync. I really wanted to get a release out ASAP, and am happy to commit more docs as they get converted to docbook (it takes time).

I think its important to get things like conflict resolution documented first, and then the data provider specific docs a bit later. As I have said, converting from the wiki (render as docbook), to the gnome docbook format takes time and help is appreciated.

John



_______________________________________________
Conduit-list mailing list
Conduit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/conduit-list


------=_Part_17831_12012379.1205846269161-- From john.stowers@gmail.com Tue Mar 18 13:24:24 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8EE467500E9 for ; Tue, 18 Mar 2008 13:24:24 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, HTML_00_10=0.795, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 4060 hrs), (distance 16, link: (Google 2)), [66.249.92.171] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsxGzpPovMJx for ; Tue, 18 Mar 2008 13:24:19 +0000 (GMT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by menubar.gnome.org (Postfix) with ESMTP id EEA38750129 for ; Tue, 18 Mar 2008 13:24:18 +0000 (GMT) Received: by ug-out-1314.google.com with SMTP id c2so754525ugf.30 for ; Tue, 18 Mar 2008 06:24:17 -0700 (PDT) Received: by 10.142.143.7 with SMTP id q7mr898604wfd.3.1205846655016; Tue, 18 Mar 2008 06:24:15 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Tue, 18 Mar 2008 06:24:14 -0700 (PDT) Message-ID: <7e40b04b0803180624y16e2d483rdb88f53c8dbfeaea@mail.gmail.com> Date: Wed, 19 Mar 2008 02:24:14 +1300 From: "John Stowers" To: Conduit Subject: Help: Autotools and gnome-doc help MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17863_33261201.1205846655007" X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 13:24:24 -0000 ------=_Part_17863_33261201.1205846655007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Well I failed at getting a release out tonight. Fails make distcheck with some errors in help about the docbook being invalid XML. It still renders fine in the help viewer though? Can anyone help me fix this so I can do a release, and propose Conduit for GNOME tomorrow? John ------=_Part_17863_33261201.1205846655007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Well I failed at getting a release out tonight. Fails make distcheck with some errors in help about the docbook being invalid XML. It still renders fine in the help viewer though?

Can anyone help me fix this so I can do a release, and propose Conduit for GNOME tomorrow?

John
------=_Part_17863_33261201.1205846655007-- From john.stowers@gmail.com Tue Mar 18 13:49:07 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A91967500EA for ; Tue, 18 Mar 2008 13:49:07 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 667 hrs), (distance 13, link: (Google 2)), [209.85.200.174] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFH+7q2nd4Oo for ; Tue, 18 Mar 2008 13:49:04 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by menubar.gnome.org (Postfix) with ESMTP id D58FD750081 for ; Tue, 18 Mar 2008 13:49:04 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so5695747wfa.9 for ; Tue, 18 Mar 2008 06:49:03 -0700 (PDT) Received: by 10.142.172.12 with SMTP id u12mr932066wfe.16.1205848143261; Tue, 18 Mar 2008 06:49:03 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Tue, 18 Mar 2008 06:49:03 -0700 (PDT) Message-ID: <7e40b04b0803180649hb33afe5v94af5cfba2c80686@mail.gmail.com> Date: Wed, 19 Mar 2008 02:49:03 +1300 From: "John Stowers" To: Conduit Subject: Re: Help: Autotools and gnome-doc help In-Reply-To: <7e40b04b0803180624y16e2d483rdb88f53c8dbfeaea@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18022_20828960.1205848143165" References: <7e40b04b0803180624y16e2d483rdb88f53c8dbfeaea@mail.gmail.com> X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 13:49:07 -0000 ------=_Part_18022_20828960.1205848143165 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Mar 19, 2008 at 2:24 AM, John Stowers wrote: > Well I failed at getting a release out tonight. Fails make distcheck with > some errors in help about the docbook being invalid XML. It still renders > fine in the help viewer though? > > Can anyone help me fix this so I can do a release, and propose Conduit for > GNOME tomorrow? I should be asleep. The problem was a shedload of missing tags Fixed now. I think > > John > ------=_Part_18022_20828960.1205848143165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Mar 19, 2008 at 2:24 AM, John Stowers <john.stowers@gmail.com> wrote:
Well I failed at getting a release out tonight. Fails make distcheck with some errors in help about the docbook being invalid XML. It still renders fine in the help viewer though?

Can anyone help me fix this so I can do a release, and propose Conduit for GNOME tomorrow?

I should be asleep. The problem was a shedload of missing <para> tags

Fixed now. I think



John

------=_Part_18022_20828960.1205848143165-- From chrismrivera@gmail.com Tue Mar 18 19:25:54 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1120E750221 for ; Tue, 18 Mar 2008 19:25:54 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001, TW_BX=0.077, TW_GT=0.077, TW_IB=0.077, TW_TK=0.077, TW_XP=0.077] X-Amavis-OS-Fingerprint: Google Wireless Transcoder (1), (distance 15, link: unknown-1468), [216.239.58.189] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7ZeGE7Q3B0Y for ; Tue, 18 Mar 2008 19:25:49 +0000 (GMT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by menubar.gnome.org (Postfix) with ESMTP id B17E7750215 for ; Tue, 18 Mar 2008 19:25:46 +0000 (GMT) Received: by gv-out-0910.google.com with SMTP id r4so37820gve.22 for ; Tue, 18 Mar 2008 12:25:44 -0700 (PDT) Received: by 10.151.110.14 with SMTP id n14mr1199085ybm.188.1205868339838; Tue, 18 Mar 2008 12:25:39 -0700 (PDT) Received: by 10.150.156.4 with HTTP; Tue, 18 Mar 2008 12:25:39 -0700 (PDT) Message-ID: <5f84803c0803181225t4006bd60m91cba6a213c8e87e@mail.gmail.com> Date: Tue, 18 Mar 2008 15:25:39 -0400 From: "Chris Rivera" To: "John Stowers" Subject: Re: [PATCH] Don't force gtkmozembed in the Facebook module In-Reply-To: <7e40b04b0803171232iacd56d8n733738c675b2e3a6@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11725_14484210.1205868339853" References: <5f84803c0803141223v1ef045b6xabe61c82cf951fb6@mail.gmail.com> <7e40b04b0803141636r244222f9g5e7bfdb8d1c4603@mail.gmail.com> <5f84803c0803142004p810ead2oee541cc9e25f2546@mail.gmail.com> <7e40b04b0803142025y1d40f24i4f657428659e1cde@mail.gmail.com> <5f84803c0803171218q4f342aeh41495446b496c2ee@mail.gmail.com> <7e40b04b0803171232iacd56d8n733738c675b2e3a6@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 19:25:54 -0000 ------=_Part_11725_14484210.1205868339853 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Mar 17, 2008 at 3:32 PM, John Stowers wrote: > > Hmm, thats a weird combination of things working/not working. The only > time I have seen something similar to what you describe is when I had ff3 > and ff2 both installed and it would find the wrong run-mozilla.sh script, > or something like that, I dont remember exactly. > > Im sorry I cant be of more help tracking this down. If conduit works on > your distribution without the wrapper script then the packagers are welcome > to remove the wrapper, like I am going to recommend is done in ubuntu 8.04conduit package -it seems to be no longer needed with ff3/gecko > 1.9 > > The problem was that run-mozilla.sh was setting LD_LIBRARY_PATH to /usr/lib/firefox. This was causing a crash in libxpcom, which is also shipped as part of xulrunner. If I avoid the run-mozilla.sh script and set MOZILLA_FIVE_HOME to the xulrunner installation then the libxpcom shared libraries shipped with xulrunner are used and everything works correctly. I would assume that since our (Novell) gtkmozembed package requires xulrunner and not firefox these are the correct versions of the libxpcom libraries to use. I changed our conduit package to look for the xulrunner installation and set MOZILLA_FIVE_HOME instead of running conduit with run-mozilla.sh. Whether you go with this change or not, the path in the conduit wrapper (currently FF_PATH) should probably begin with '/usr/lib*' instead of '/usr/lib'. The current FF_PATH doesn't work for us on 64-bit systems. I'm not sure how other distros package Firefox on 64-bit platforms though. Thoughts? Chris ------=_Part_11725_14484210.1205868339853 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Mar 17, 2008 at 3:32 PM, John Stowers <john.stowers@gmail.com> wrote:

Hmm, thats a weird combination of things working/not working. The only time I have seen something similar to what you describe is when I had ff3 and ff2 both installed and it would find the wrong run-mozilla.sh script, or something like that, I dont remember exactly.

Im sorry I cant be of more help tracking this down. If conduit works on your distribution without the wrapper script then the packagers are welcome to remove the wrapper, like I am going to recommend is done in ubuntu 8.04 conduit package -it seems to be no longer needed with ff3/gecko 1.9


The problem was that run-mozilla.sh was setting LD_LIBRARY_PATH to /usr/lib/firefox.  This was causing a crash in libxpcom, which is also shipped as part of xulrunner.  If I avoid the run-mozilla.sh script and set MOZILLA_FIVE_HOME to the xulrunner installation then the libxpcom shared libraries shipped with xulrunner are used and everything works correctly.  I would assume that since our (Novell) gtkmozembed package requires xulrunner and not firefox these are the correct versions of the libxpcom libraries to use.

I changed our conduit package to look for the xulrunner installation and set MOZILLA_FIVE_HOME instead of running conduit with run-mozilla.sh.

Whether you go with this change or not, the path in the conduit wrapper (currently FF_PATH) should probably begin with '/usr/lib*' instead of '/usr/lib'.  The current FF_PATH doesn't work for us on 64-bit systems.  I'm not sure how other distros package Firefox on 64-bit platforms though.  Thoughts?

Chris
------=_Part_11725_14484210.1205868339853-- From john.stowers@gmail.com Wed Mar 19 09:31:55 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F32E5750095 for ; Wed, 19 Mar 2008 09:31:54 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 864 hrs), (distance 12, link: (Google 2)), [209.85.200.172] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXWB37gtY1ZM for ; Wed, 19 Mar 2008 09:31:50 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by menubar.gnome.org (Postfix) with ESMTP id 839407500D1 for ; Wed, 19 Mar 2008 09:31:50 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so320053wfa.9 for ; Wed, 19 Mar 2008 02:31:49 -0700 (PDT) Received: by 10.142.229.4 with SMTP id b4mr23472wfh.125.1205919108983; Wed, 19 Mar 2008 02:31:48 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Wed, 19 Mar 2008 02:31:48 -0700 (PDT) Message-ID: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> Date: Wed, 19 Mar 2008 22:31:49 +1300 From: "John Stowers" To: gnome-announce-list@gnome.org, Conduit Subject: ANNOUNCE: Conduit 0.3.9 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 09:31:55 -0000 Hey Everyone! I am proud to announce that Conduit 0.3.9 is now available for download fro= m: * http://download.gnome.org/sources/conduit/0.3/ What is it? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Conduit is a synchronization application for GNOME. It allows you to synchronize your files, photos, emails, contacts, notes, calendar data and any other type of personal information and synchronize that data with another computer, an online service, or even another electronic device. Conduit manages the synchronization and conversion of data into other forma= ts. For example, Conduit allows you to; * Synchronize your Tomboy notes with another computer * Synchronize your your PIM data to your mobile phone, iPod, Nokia Internet tablet, or between computers * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your iPod, * ... and many more Any combination you can imagine, Conduit will take care of the conversion and synchronization. Where can I find out more? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D * Website: http://www.conduit-project.org/ * Screenshots/Screencast: http://www.conduit-project.org/wiki/Screenshots * Mailing List: http://mail.gnome.org/mailman/listinfo/conduit-list * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=3Dconduit What's New? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Add Conduit documentation (Brent Gueth) * You can now specify your own labels when saving emails * Removed the build dependency on dbus, just check for python-dbus > 0.80.0 * Restore the expanded columns in the data provider pane * Improved removable volume support (like USB keys). Now, inserting a USB key that has been synchronized on another computer will automatically cre= ate a preconfigured dataprovider for synchronizing the folders of interest. Bugs Fixed: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Fixed #510124, Cant cancel sync without closing conduit (John Stowers) * Fixed #511691, Improve removable folder support (John Stowers) * Fixed #512230, 'Folder' should display as folder_name (John Stowers) * Fixed #515328, There is NO documentation (Brent Gueth) * Fixed #518592, Get rid of .conduit and follow fd.o specifications (John Stowers) * Fixed #518704, Youtube download doesnt work for old videos (Thomas Van Machelen) * Fixed #519708, TomboyModole says note with unicode characters in title has disappeared (Thomas Van Machelen) * Fixed #521194, Add "caption" support to Photos/Images (Matt Brown) * Fixed #521349, Sync icons in status bar keep 'turning around' (Thomas Van Machelen) * Fixed #522436, Conduit fails to sync files with special character % in filename (John Stowers) Translations: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Updated fr: St=E9phane Raimbault * Updated pt_BR: Leonardo Ferreira Fontenelle * Updated pt: Duarte Loreto * Updated ca: Gil Forcada * Updated it: Luca Ferretti * Updated sv: Daniel Nylander * Updated es: Jorge Gonzalez * Updated nb: Kjartan Maraas * Updated en_GB: Philip Withnall Manual Translations: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Updated es: John Stowers What Can Conduit Do: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For a list of all the services that conduit supports see * http://www.conduit-project.org/wiki/SyncStatus Conduit can perform one-way and two-synchronization (and conversion/transco= ding) of data between locations. In one-way sync/export conduit will only replace exising data if the new copy has been modified. It can also optionally dele= te data if the original has been deleted. Conduit has a complete DBus interface to allow other application authors to use Conduit to perform the synchronization and export tasks of their applications. 19 March 2008 Conduit team From mike@weingutjanson.de Wed Mar 19 12:04:43 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DE7B750090 for ; Wed, 19 Mar 2008 12:04:43 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, L_P0F_Unix=-1] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 24, link: ethernet/modem), [81.169.146.160] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfeBfsObSCsj for ; Wed, 19 Mar 2008 12:04:36 +0000 (GMT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by menubar.gnome.org (Postfix) with ESMTP id CE3117500EE for ; Wed, 19 Mar 2008 12:04:35 +0000 (GMT) X-RZG-CLASS-ID: mo00 X-RZG-AUTH: j/CaJeme7nlEtYNA3j3ew1Hw+tWgCbDZdXkc/FstCbbOnuGey+87Fr0SIg== Received: from [192.168.1.2] (p5B166D09.dip.t-dialin.net [91.22.109.9]) by post.webmailer.de (mrclete mo58) (RZmta 16.13) with ESMTP id p04994k2JAuaNk for ; Wed, 19 Mar 2008 13:04:32 +0100 (MET) (envelope-from: ) Subject: Re: ANNOUNCE: Conduit 0.3.9 From: Mike =?ISO-8859-1?Q?Gem=FCnde?= To: Conduit In-Reply-To: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Date: Wed, 19 Mar 2008 13:04:31 +0100 Message-Id: <1205928271.6522.15.camel@bamboocha> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 8bit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 12:04:44 -0000 Hi, nice work. But just 2 things ;-) 1) I just tried it out and got some strange behaviour with folders. Than I read in the manual (great work), that the names for 2 folders have to be the same. After I changed the names it works fine. But why there are 2 names, when it have to be the same? 2) After sync I looked at the removeable device and found the .conduit file. But it just contains the last finished group. (I sync more than one group to an usb-drive). nevertheless, great work Am Mittwoch, den 19.03.2008, 22:31 +1300 schrieb John Stowers: > Hey Everyone! > > I am proud to announce that Conduit 0.3.9 is now available for download from: > * http://download.gnome.org/sources/conduit/0.3/ > > What is it? > =========== > Conduit is a synchronization application for GNOME. It allows you to > synchronize your files, photos, emails, contacts, notes, calendar data > and any other type of personal information and synchronize that data > with another computer, an online service, or even another electronic > device. > > Conduit manages the synchronization and conversion of data into other formats. > For example, Conduit allows you to; > * Synchronize your Tomboy notes with another computer > * Synchronize your your PIM data to your mobile phone, iPod, > Nokia Internet tablet, or between computers > * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your iPod, > * ... and many more > > Any combination you can imagine, Conduit will take care of the conversion > and synchronization. > > Where can I find out more? > ========================== > * Website: http://www.conduit-project.org/ > * Screenshots/Screencast: http://www.conduit-project.org/wiki/Screenshots > * Mailing List: http://mail.gnome.org/mailman/listinfo/conduit-list > * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=conduit > > What's New? > =========== > * Add Conduit documentation (Brent Gueth) > * You can now specify your own labels when saving emails > * Removed the build dependency on dbus, just check for python-dbus > 0.80.0 > * Restore the expanded columns in the data provider pane > * Improved removable volume support (like USB keys). Now, inserting a USB > key that has been synchronized on another computer will automatically create > a preconfigured dataprovider for synchronizing the folders of interest. > > Bugs Fixed: > =========== > * Fixed #510124, Cant cancel sync without closing conduit (John Stowers) > * Fixed #511691, Improve removable folder support (John Stowers) > * Fixed #512230, 'Folder' should display as folder_name (John Stowers) > * Fixed #515328, There is NO documentation (Brent Gueth) > * Fixed #518592, Get rid of .conduit and follow fd.o specifications > (John Stowers) > * Fixed #518704, Youtube download doesnt work for old videos (Thomas > Van Machelen) > * Fixed #519708, TomboyModole says note with unicode characters in > title has disappeared (Thomas Van Machelen) > * Fixed #521194, Add "caption" support to Photos/Images (Matt Brown) > * Fixed #521349, Sync icons in status bar keep 'turning around' > (Thomas Van Machelen) > * Fixed #522436, Conduit fails to sync files with special character % > in filename (John Stowers) > > Translations: > ============= > * Updated fr: Stéphane Raimbault > * Updated pt_BR: Leonardo Ferreira Fontenelle > * Updated pt: Duarte Loreto > * Updated ca: Gil Forcada > * Updated it: Luca Ferretti > * Updated sv: Daniel Nylander > * Updated es: Jorge Gonzalez > * Updated nb: Kjartan Maraas > * Updated en_GB: Philip Withnall > > Manual Translations: > ==================== > * Updated es: John Stowers > > What Can Conduit Do: > ==================== > For a list of all the services that conduit supports see > * http://www.conduit-project.org/wiki/SyncStatus > > Conduit can perform one-way and two-synchronization (and conversion/transcoding) > of data between locations. In one-way sync/export conduit will only replace > exising data if the new copy has been modified. It can also optionally delete > data if the original has been deleted. > > Conduit has a complete DBus interface to allow other application authors to > use Conduit to perform the synchronization and export tasks of their > applications. > > 19 March 2008 > Conduit team > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list From creeva@gmail.com Wed Mar 19 14:32:58 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B86BC750093 for ; Wed, 19 Mar 2008 14:32:58 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11444 hrs), (distance 13, link: (Google 2)), [209.85.142.187] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQgn2b+9BXV9 for ; Wed, 19 Mar 2008 14:32:53 +0000 (GMT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by menubar.gnome.org (Postfix) with ESMTP id 78EE1750066 for ; Wed, 19 Mar 2008 14:32:52 +0000 (GMT) Received: by ti-out-0910.google.com with SMTP id b8so144729tic.1 for ; Wed, 19 Mar 2008 07:32:50 -0700 (PDT) Received: by 10.110.11.10 with SMTP id 10mr30541tik.44.1205937170441; Wed, 19 Mar 2008 07:32:50 -0700 (PDT) Received: by 10.70.116.5 with HTTP; Wed, 19 Mar 2008 07:32:50 -0700 (PDT) Message-ID: <2510ddab0803190732y5949a933h1f51ab7ce35b36bd@mail.gmail.com> Date: Wed, 19 Mar 2008 10:32:50 -0400 From: "Brent Gueth" To: "=?ISO-8859-1?Q?Mike_Gem=FCnde?=" Subject: Re: ANNOUNCE: Conduit 0.3.9 In-Reply-To: <1205928271.6522.15.camel@bamboocha> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12781_26689708.1205937170145" References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> <1205928271.6522.15.camel@bamboocha> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 14:32:58 -0000 ------=_Part_12781_26689708.1205937170145 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (excuse I'm going off of 0.3.8 haven't gotten to work on 0.3.9 yet - I will tonight) 1. Are you doing a folder sync or a file sync - if you are using a file syn= c the folders can be different names, If you are doing a folder sync I believe they need to be identical. 2. May have to do a change request to track all changes - the only problem I see with this is a limit will need to be specified otherwise it will just grow and grow. On Wed, Mar 19, 2008 at 8:04 AM, Mike Gem=FCnde wro= te: > Hi, > > > nice work. But just 2 things ;-) > > 1) I just tried it out and got some strange behaviour with folders. Than > I read in the manual (great work), that the names for 2 folders have to > be the same. After I changed the names it works fine. But why there are > 2 names, when it have to be the same? > > 2) After sync I looked at the removeable device and found the .conduit > file. But it just contains the last finished group. (I sync more than > one group to an usb-drive). > > nevertheless, > great work > > > > > Am Mittwoch, den 19.03.2008, 22:31 +1300 schrieb John Stowers: > > Hey Everyone! > > > > I am proud to announce that Conduit 0.3.9 is now available for download > from: > > * http://download.gnome.org/sources/conduit/0.3/ > > > > What is it? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Conduit is a synchronization application for GNOME. It allows you to > > synchronize your files, photos, emails, contacts, notes, calendar data > > and any other type of personal information and synchronize that data > > with another computer, an online service, or even another electronic > > device. > > > > Conduit manages the synchronization and conversion of data into other > formats. > > For example, Conduit allows you to; > > * Synchronize your Tomboy notes with another computer > > * Synchronize your your PIM data to your mobile phone, iPod, > > Nokia Internet tablet, or between computers > > * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your iPod, > > * ... and many more > > > > Any combination you can imagine, Conduit will take care of the > conversion > > and synchronization. > > > > Where can I find out more? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > * Website: http://www.conduit-project.org/ > > * Screenshots/Screencast: > http://www.conduit-project.org/wiki/Screenshots > > * Mailing List: http://mail.gnome.org/mailman/listinfo/conduit-list > > * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=3Dconduit > > > > What's New? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Add Conduit documentation (Brent Gueth) > > * You can now specify your own labels when saving emails > > * Removed the build dependency on dbus, just check for python-dbus > > 0.80.0 > > * Restore the expanded columns in the data provider pane > > * Improved removable volume support (like USB keys). Now, inserting a > USB > > key that has been synchronized on another computer will automatically > create > > a preconfigured dataprovider for synchronizing the folders of > interest. > > > > Bugs Fixed: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Fixed #510124, Cant cancel sync without closing conduit (John Stowers= ) > > * Fixed #511691, Improve removable folder support (John Stowers) > > * Fixed #512230, 'Folder' should display as folder_name (John Stowers) > > * Fixed #515328, There is NO documentation (Brent Gueth) > > * Fixed #518592, Get rid of .conduit and follow fd.o specifications > > (John Stowers) > > * Fixed #518704, Youtube download doesnt work for old videos (Thomas > > Van Machelen) > > * Fixed #519708, TomboyModole says note with unicode characters in > > title has disappeared (Thomas Van Machelen) > > * Fixed #521194, Add "caption" support to Photos/Images (Matt Brown) > > * Fixed #521349, Sync icons in status bar keep 'turning around' > > (Thomas Van Machelen) > > * Fixed #522436, Conduit fails to sync files with special character % > > in filename (John Stowers) > > > > Translations: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Updated fr: St=E9phane Raimbault > > * Updated pt_BR: Leonardo Ferreira Fontenelle > > * Updated pt: Duarte Loreto > > * Updated ca: Gil Forcada > > * Updated it: Luca Ferretti > > * Updated sv: Daniel Nylander > > * Updated es: Jorge Gonzalez > > * Updated nb: Kjartan Maraas > > * Updated en_GB: Philip Withnall > > > > Manual Translations: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Updated es: John Stowers > > > > What Can Conduit Do: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > For a list of all the services that conduit supports see > > * http://www.conduit-project.org/wiki/SyncStatus > > > > Conduit can perform one-way and two-synchronization (and > conversion/transcoding) > > of data between locations. In one-way sync/export conduit will only > replace > > exising data if the new copy has been modified. It can also optionally > delete > > data if the original has been deleted. > > > > Conduit has a complete DBus interface to allow other application author= s > to > > use Conduit to perform the synchronization and export tasks of their > > applications. > > > > 19 March 2008 > > Conduit team > > _______________________________________________ > > Conduit-list mailing list > > Conduit-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/conduit-list > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > ------=_Part_12781_26689708.1205937170145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (excuse I'm going off of 0.3.8 haven't gotten to work on 0.3.9 yet = - I will tonight)

1. Are you doing a folder sync or a file sync - if= you are using a file sync the folders can be different names,   = If you are doing a folder sync I believe they need to be identical.

2.  May have to do a change request to track all changes - the onl= y problem I see with this is a limit will need to be specified otherwise it= will just grow and grow.

On Wed, Mar 19= , 2008 at 8:04 AM, Mike Gem=FCnde <mike@weingutjanson.de> wrote:
Hi,


nice work. But just 2 things ;-)

1) I just tried it out and got some strange behaviour with folders. Than I read in the manual (great work), that the names for 2 folders have to
be the same. After I changed the names it works fine. But why there are
2 names, when it have to be the same?

2) After sync I looked at the removeable device and found the .conduit
file. But it just contains the last finished group. (I sync more than
one group to an usb-drive).

nevertheless,
great work




Am Mittwoch, den 19.03.2008, 22:31 +1300 schrieb John Stowers:
> Hey Everyone!
>
> I am proud to announce that Conduit 0.3.9 is now available for downloa= d from:
>  * http://download.gnome.org/sources/conduit/0.3/
>
> What is it?
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Conduit is a synchronization application for GNOME. It allows you to > synchronize your files, photos, emails, contacts, notes, calendar data=
> and any other type of personal information and synchronize that data > with another computer, an online service, or even another electronic > device.
>
> Conduit manages the synchronization and conversion of data into other = formats.
> For example, Conduit allows you to;
>  * Synchronize your Tomboy notes with another computer
>  * Synchronize your your PIM data to your mobile phone, iPod,
>    Nokia Internet tablet, or between computers
>  * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your = iPod,
>  * ... and many more
>
> Any combination you can imagine, Conduit will take care of the convers= ion
> and synchronization.
>
> Where can I find out more?
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>  * Website: http://www.conduit-project.org/
>  * Screenshots/Screencast: http://www.conduit-project.org/wiki= /Screenshots
>  * Mailing List: http://mail.gnome.org/mailman/listinfo/co= nduit-list
>  * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?pro= duct=3Dconduit
>
> What's New?
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> * Add Conduit documentation (Brent Gueth)
> * You can now specify your own labels when saving emails
> * Removed the build dependency on dbus, just check for python-dbus >= ; 0.80.0
> * Restore the expanded columns in the data provider pane
> * Improved removable volume support (like USB keys). Now, inserting a = USB
>   key that has been synchronized on another computer will automat= ically create
>   a preconfigured dataprovider for synchronizing the folders of i= nterest.
>
> Bugs Fixed:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> * Fixed #510124, Cant cancel sync without closing conduit (John Stower= s)
> * Fixed #511691, Improve removable folder support (John Stowers)
> * Fixed #512230, 'Folder' should display as folder_name (John = Stowers)
> * Fixed #515328, There is NO documentation (Brent Gueth)
> * Fixed #518592, Get rid of .conduit and follow fd.o specifications > (John Stowers)
> * Fixed #518704, Youtube download doesnt work for old videos (Thomas > Van Machelen)
> * Fixed #519708, TomboyModole says note with unicode characters in
> title has disappeared (Thomas Van Machelen)
> * Fixed #521194, Add "caption" support to Photos/Images (Mat= t Brown)
> * Fixed #521349, Sync icons in status bar keep 'turning around'= ;
> (Thomas Van Machelen)
> * Fixed #522436, Conduit fails to sync files with special character %<= br> > in filename (John Stowers)
>
> Translations:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> * Updated fr: St=E9phane Raimbault
> * Updated pt_BR: Leonardo Ferreira Fontenelle
> * Updated pt: Duarte Loreto
> * Updated ca: Gil Forcada
> * Updated it: Luca Ferretti
> * Updated sv: Daniel Nylander
> * Updated es: Jorge Gonzalez
> * Updated nb: Kjartan Maraas
> * Updated en_GB: Philip Withnall
>
> Manual Translations:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> * Updated es: John Stowers
>
> What Can Conduit Do:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> For a list of all the services that conduit supports see
>  * http://www.conduit-project.org/wiki/SyncStatus
>
> Conduit can perform one-way and two-synchronization (and conversion/tr= anscoding)
> of data between locations. In one-way sync/export conduit will only re= place
> exising data if the new copy has been modified. It can also optionally= delete
> data if the original has been deleted.
>
> Conduit has a complete DBus interface to allow other application autho= rs to
> use Conduit to perform the synchronization and export tasks of their > applications.
>
> 19 March 2008
> Conduit team
> _______________________________________________
> Conduit-list mailing list
> Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list

_______________________________________________
Conduit-list mailing list
Conduit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/conduit-list

------=_Part_12781_26689708.1205937170145-- From john.stowers@gmail.com Wed Mar 19 19:43:11 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 02C97750212 for ; Wed, 19 Mar 2008 19:43:11 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 966 hrs), (distance 12, link: (Google 2)), [209.85.200.174] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8C1rnIfx1bC for ; Wed, 19 Mar 2008 19:43:05 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by menubar.gnome.org (Postfix) with ESMTP id E6155750066 for ; Wed, 19 Mar 2008 19:43:04 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so554190wfa.9 for ; Wed, 19 Mar 2008 12:43:03 -0700 (PDT) Received: by 10.142.83.4 with SMTP id g4mr603808wfb.28.1205955783298; Wed, 19 Mar 2008 12:43:03 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Wed, 19 Mar 2008 12:43:03 -0700 (PDT) Message-ID: <7e40b04b0803191243g6710f6c6t6b2d893ae26006ba@mail.gmail.com> Date: Thu, 20 Mar 2008 08:43:03 +1300 From: "John Stowers" To: "=?ISO-8859-1?Q?Mike_Gem=FCnde?=" Subject: Re: ANNOUNCE: Conduit 0.3.9 In-Reply-To: <1205928271.6522.15.camel@bamboocha> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> <1205928271.6522.15.camel@bamboocha> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 19:43:11 -0000 On Thu, Mar 20, 2008 at 1:04 AM, Mike Gem=FCnde wro= te: > Hi, > > > nice work. But just 2 things ;-) > > 1) I just tried it out and got some strange behaviour with folders. Than > I read in the manual (great work), that the names for 2 folders have to > be the same. After I changed the names it works fine. But why there are > 2 names, when it have to be the same? To accommodate multiple sources (with different names), to the same destination. The logic is if names the same ---> Put files if names not the same ---> Put files in subdirectory with the name of the source But you may be correct. The idea is a bit confusing. > > 2) After sync I looked at the removeable device and found the .conduit > file. But it just contains the last finished group. (I sync more than > one group to an usb-drive). This one is a bug. Can you file it in bugzilla please? > > nevertheless, > great work Thanks > > > > > Am Mittwoch, den 19.03.2008, 22:31 +1300 schrieb John Stowers: > > > > Hey Everyone! > > > > I am proud to announce that Conduit 0.3.9 is now available for downloa= d from: > > * http://download.gnome.org/sources/conduit/0.3/ > > > > What is it? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Conduit is a synchronization application for GNOME. It allows you to > > synchronize your files, photos, emails, contacts, notes, calendar data > > and any other type of personal information and synchronize that data > > with another computer, an online service, or even another electronic > > device. > > > > Conduit manages the synchronization and conversion of data into other = formats. > > For example, Conduit allows you to; > > * Synchronize your Tomboy notes with another computer > > * Synchronize your your PIM data to your mobile phone, iPod, > > Nokia Internet tablet, or between computers > > * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your iPod, > > * ... and many more > > > > Any combination you can imagine, Conduit will take care of the convers= ion > > and synchronization. > > > > Where can I find out more? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > * Website: http://www.conduit-project.org/ > > * Screenshots/Screencast: http://www.conduit-project.org/wiki/Screens= hots > > * Mailing List: http://mail.gnome.org/mailman/listinfo/conduit-list > > * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=3Dconduit > > > > What's New? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Add Conduit documentation (Brent Gueth) > > * You can now specify your own labels when saving emails > > * Removed the build dependency on dbus, just check for python-dbus > 0= .80.0 > > * Restore the expanded columns in the data provider pane > > * Improved removable volume support (like USB keys). Now, inserting a = USB > > key that has been synchronized on another computer will automaticall= y create > > a preconfigured dataprovider for synchronizing the folders of intere= st. > > > > Bugs Fixed: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Fixed #510124, Cant cancel sync without closing conduit (John Stower= s) > > * Fixed #511691, Improve removable folder support (John Stowers) > > * Fixed #512230, 'Folder' should display as folder_name (John Stowers) > > * Fixed #515328, There is NO documentation (Brent Gueth) > > * Fixed #518592, Get rid of .conduit and follow fd.o specifications > > (John Stowers) > > * Fixed #518704, Youtube download doesnt work for old videos (Thomas > > Van Machelen) > > * Fixed #519708, TomboyModole says note with unicode characters in > > title has disappeared (Thomas Van Machelen) > > * Fixed #521194, Add "caption" support to Photos/Images (Matt Brown) > > * Fixed #521349, Sync icons in status bar keep 'turning around' > > (Thomas Van Machelen) > > * Fixed #522436, Conduit fails to sync files with special character % > > in filename (John Stowers) > > > > Translations: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Updated fr: St=E9phane Raimbault > > * Updated pt_BR: Leonardo Ferreira Fontenelle > > * Updated pt: Duarte Loreto > > * Updated ca: Gil Forcada > > * Updated it: Luca Ferretti > > * Updated sv: Daniel Nylander > > * Updated es: Jorge Gonzalez > > * Updated nb: Kjartan Maraas > > * Updated en_GB: Philip Withnall > > > > Manual Translations: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Updated es: John Stowers > > > > What Can Conduit Do: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > For a list of all the services that conduit supports see > > * http://www.conduit-project.org/wiki/SyncStatus > > > > Conduit can perform one-way and two-synchronization (and conversion/tr= anscoding) > > of data between locations. In one-way sync/export conduit will only re= place > > exising data if the new copy has been modified. It can also optionally= delete > > data if the original has been deleted. > > > > Conduit has a complete DBus interface to allow other application autho= rs to > > use Conduit to perform the synchronization and export tasks of their > > applications. > > > > 19 March 2008 > > Conduit team > > > _______________________________________________ > > Conduit-list mailing list > > Conduit-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/conduit-list > > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/conduit-list > From Jijun.Yu@Sun.COM Thu Mar 20 11:54:12 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 25CAD75008B; Thu, 20 Mar 2008 11:54:12 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=2 tests=[AWL=0.345, BAYES_00=-2.599, L_P0F_Unix=-1, UNPARSEABLE_RELAY=0.001] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 19, link: ethernet/modem), [192.18.19.7] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUnFVFs5i2It; Thu, 20 Mar 2008 11:54:04 +0000 (GMT) Received: from sineb-mail-2.sun.com (sineb-mail-2.sun.com [192.18.19.7]) by menubar.gnome.org (Postfix) with ESMTP id 4C493750217; Thu, 20 Mar 2008 11:54:03 +0000 (GMT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2KBsOE4026523; Thu, 20 Mar 2008 11:54:24 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JY100A0127EC600@mail-apac.sun.com> (original mail from Jijun.Yu@Sun.COM) ; Thu, 20 Mar 2008 19:53:52 +0800 (SGT) Received: from [129.158.217.211] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JY100BTY2DRMFLY@mail-apac.sun.com>; Thu, 20 Mar 2008 19:53:52 +0800 (SGT) Date: Thu, 20 Mar 2008 19:53:40 +0800 From: jijun yu Subject: Re: ANNOUNCE: Conduit 0.3.9 In-reply-to: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> Sender: Jijun.Yu@Sun.COM To: John Stowers Message-id: <47E25044.9070701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Cc: gnome-announce-list@gnome.org, Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 11:54:12 -0000 For box.net, it seems that a browser applet should be loaded and have the user log in to authorize the application every time one start Coduit and to do sync. But for me, there's no such browser applet loaded? Why? Anything I missed or should I do some configuration for? Thanks, Jerry John Stowers wrote: > Hey Everyone! > > I am proud to announce that Conduit 0.3.9 is now available for download from: > * http://download.gnome.org/sources/conduit/0.3/ > > What is it? > =========== > Conduit is a synchronization application for GNOME. It allows you to > synchronize your files, photos, emails, contacts, notes, calendar data > and any other type of personal information and synchronize that data > with another computer, an online service, or even another electronic > device. > > Conduit manages the synchronization and conversion of data into other formats. > For example, Conduit allows you to; > * Synchronize your Tomboy notes with another computer > * Synchronize your your PIM data to your mobile phone, iPod, > Nokia Internet tablet, or between computers > * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your iPod, > * ... and many more > > Any combination you can imagine, Conduit will take care of the conversion > and synchronization. > > Where can I find out more? > ========================== > * Website: http://www.conduit-project.org/ > * Screenshots/Screencast: http://www.conduit-project.org/wiki/Screenshots > * Mailing List: http://mail.gnome.org/mailman/listinfo/conduit-list > * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=conduit > > What's New? > =========== > * Add Conduit documentation (Brent Gueth) > * You can now specify your own labels when saving emails > * Removed the build dependency on dbus, just check for python-dbus > 0.80.0 > * Restore the expanded columns in the data provider pane > * Improved removable volume support (like USB keys). Now, inserting a USB > key that has been synchronized on another computer will automatically create > a preconfigured dataprovider for synchronizing the folders of interest. > > Bugs Fixed: > =========== > * Fixed #510124, Cant cancel sync without closing conduit (John Stowers) > * Fixed #511691, Improve removable folder support (John Stowers) > * Fixed #512230, 'Folder' should display as folder_name (John Stowers) > * Fixed #515328, There is NO documentation (Brent Gueth) > * Fixed #518592, Get rid of .conduit and follow fd.o specifications > (John Stowers) > * Fixed #518704, Youtube download doesnt work for old videos (Thomas > Van Machelen) > * Fixed #519708, TomboyModole says note with unicode characters in > title has disappeared (Thomas Van Machelen) > * Fixed #521194, Add "caption" support to Photos/Images (Matt Brown) > * Fixed #521349, Sync icons in status bar keep 'turning around' > (Thomas Van Machelen) > * Fixed #522436, Conduit fails to sync files with special character % > in filename (John Stowers) > > Translations: > ============= > * Updated fr: Stéphane Raimbault > * Updated pt_BR: Leonardo Ferreira Fontenelle > * Updated pt: Duarte Loreto > * Updated ca: Gil Forcada > * Updated it: Luca Ferretti > * Updated sv: Daniel Nylander > * Updated es: Jorge Gonzalez > * Updated nb: Kjartan Maraas > * Updated en_GB: Philip Withnall > > Manual Translations: > ==================== > * Updated es: John Stowers > > What Can Conduit Do: > ==================== > For a list of all the services that conduit supports see > * http://www.conduit-project.org/wiki/SyncStatus > > Conduit can perform one-way and two-synchronization (and conversion/transcoding) > of data between locations. In one-way sync/export conduit will only replace > exising data if the new copy has been modified. It can also optionally delete > data if the original has been deleted. > > Conduit has a complete DBus interface to allow other application authors to > use Conduit to perform the synchronization and export tasks of their > applications. > > 19 March 2008 > Conduit team > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > From mike@weingutjanson.de Thu Mar 20 16:19:11 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BD5F3750351 for ; Thu, 20 Mar 2008 16:19:11 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=2 tests=[AWL=0.877, BAYES_00=-2.599, L_P0F_Unix=-1] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 25, link: ethernet/modem), [81.169.146.162] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyYzjxktCvyY for ; Thu, 20 Mar 2008 16:19:03 +0000 (GMT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by menubar.gnome.org (Postfix) with ESMTP id 2E8BB7502FA for ; Thu, 20 Mar 2008 16:19:02 +0000 (GMT) X-RZG-CLASS-ID: mo00 X-RZG-AUTH: j/CaJeme7nlEtYNA3j3ew1Hw+tWgCbDZdXkc/FstCb0WbOlFLDjtDajDOpJM Received: from [192.168.0.102] (pD957D835.dip.t-dialin.net [217.87.216.53]) by post.webmailer.de (klopstock mo60) (RZmta 16.15) with ESMTP id x0173ak2KF6bo5 ; Thu, 20 Mar 2008 17:18:59 +0100 (MET) (envelope-from: ) Subject: Re: ANNOUNCE: Conduit 0.3.9 From: Mike =?ISO-8859-1?Q?Gem=FCnde?= To: John Stowers In-Reply-To: <7e40b04b0803191243g6710f6c6t6b2d893ae26006ba@mail.gmail.com> References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> <1205928271.6522.15.camel@bamboocha> <7e40b04b0803191243g6710f6c6t6b2d893ae26006ba@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Date: Thu, 20 Mar 2008 17:18:59 +0100 Message-Id: <1206029939.13886.7.camel@orange> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 8bit Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 16:19:12 -0000 Hi, > To accommodate multiple sources (with different names), to the same > destination. The logic is > if names the same > ---> Put files > if names not the same > ---> Put files in subdirectory with the name of the source > > But you may be correct. The idea is a bit confusing. Ok, If I want to have this behaviour, I would first create the subdirectories and than create the sync group pointing to these subdirectories. Maybe a checkbox with "create subdirectory" could be more explanatory for the user. The other thing is, that this behavior still occurs whith a two-way-sync between 2 directories. This result is not really useable. Here (I think) the names should be ignored. > > > 2) After sync I looked at the removeable device and found the .conduit > > file. But it just contains the last finished group. (I sync more than > > one group to an usb-drive). > > This one is a bug. Can you file it in bugzilla please? done. thx for the answers Mike Am Donnerstag, den 20.03.2008, 08:43 +1300 schrieb John Stowers: > On Thu, Mar 20, 2008 at 1:04 AM, Mike Gemünde wrote: > > Hi, > > > > > > nice work. But just 2 things ;-) > > > > 1) I just tried it out and got some strange behaviour with folders. Than > > I read in the manual (great work), that the names for 2 folders have to > > be the same. After I changed the names it works fine. But why there are > > 2 names, when it have to be the same? > > To accommodate multiple sources (with different names), to the same > destination. The logic is > if names the same > ---> Put files > if names not the same > ---> Put files in subdirectory with the name of the source > > But you may be correct. The idea is a bit confusing. > > > > > 2) After sync I looked at the removeable device and found the .conduit > > file. But it just contains the last finished group. (I sync more than > > one group to an usb-drive). > > This one is a bug. Can you file it in bugzilla please? > > > > > nevertheless, > > great work > > Thanks > > > > > > > > > > > > Am Mittwoch, den 19.03.2008, 22:31 +1300 schrieb John Stowers: > > > > > > > Hey Everyone! > > > > > > I am proud to announce that Conduit 0.3.9 is now available for download from: > > > * http://download.gnome.org/sources/conduit/0.3/ > > > > > > What is it? > > > =========== > > > Conduit is a synchronization application for GNOME. It allows you to > > > synchronize your files, photos, emails, contacts, notes, calendar data > > > and any other type of personal information and synchronize that data > > > with another computer, an online service, or even another electronic > > > device. > > > > > > Conduit manages the synchronization and conversion of data into other formats. > > > For example, Conduit allows you to; > > > * Synchronize your Tomboy notes with another computer > > > * Synchronize your your PIM data to your mobile phone, iPod, > > > Nokia Internet tablet, or between computers > > > * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your iPod, > > > * ... and many more > > > > > > Any combination you can imagine, Conduit will take care of the conversion > > > and synchronization. > > > > > > Where can I find out more? > > > ========================== > > > * Website: http://www.conduit-project.org/ > > > * Screenshots/Screencast: http://www.conduit-project.org/wiki/Screenshots > > > * Mailing List: http://mail.gnome.org/mailman/listinfo/conduit-list > > > * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=conduit > > > > > > What's New? > > > =========== > > > * Add Conduit documentation (Brent Gueth) > > > * You can now specify your own labels when saving emails > > > * Removed the build dependency on dbus, just check for python-dbus > 0.80.0 > > > * Restore the expanded columns in the data provider pane > > > * Improved removable volume support (like USB keys). Now, inserting a USB > > > key that has been synchronized on another computer will automatically create > > > a preconfigured dataprovider for synchronizing the folders of interest. > > > > > > Bugs Fixed: > > > =========== > > > * Fixed #510124, Cant cancel sync without closing conduit (John Stowers) > > > * Fixed #511691, Improve removable folder support (John Stowers) > > > * Fixed #512230, 'Folder' should display as folder_name (John Stowers) > > > * Fixed #515328, There is NO documentation (Brent Gueth) > > > * Fixed #518592, Get rid of .conduit and follow fd.o specifications > > > (John Stowers) > > > * Fixed #518704, Youtube download doesnt work for old videos (Thomas > > > Van Machelen) > > > * Fixed #519708, TomboyModole says note with unicode characters in > > > title has disappeared (Thomas Van Machelen) > > > * Fixed #521194, Add "caption" support to Photos/Images (Matt Brown) > > > * Fixed #521349, Sync icons in status bar keep 'turning around' > > > (Thomas Van Machelen) > > > * Fixed #522436, Conduit fails to sync files with special character % > > > in filename (John Stowers) > > > > > > Translations: > > > ============= > > > * Updated fr: Stéphane Raimbault > > > * Updated pt_BR: Leonardo Ferreira Fontenelle > > > * Updated pt: Duarte Loreto > > > * Updated ca: Gil Forcada > > > * Updated it: Luca Ferretti > > > * Updated sv: Daniel Nylander > > > * Updated es: Jorge Gonzalez > > > * Updated nb: Kjartan Maraas > > > * Updated en_GB: Philip Withnall > > > > > > Manual Translations: > > > ==================== > > > * Updated es: John Stowers > > > > > > What Can Conduit Do: > > > ==================== > > > For a list of all the services that conduit supports see > > > * http://www.conduit-project.org/wiki/SyncStatus > > > > > > Conduit can perform one-way and two-synchronization (and conversion/transcoding) > > > of data between locations. In one-way sync/export conduit will only replace > > > exising data if the new copy has been modified. It can also optionally delete > > > data if the original has been deleted. > > > > > > Conduit has a complete DBus interface to allow other application authors to > > > use Conduit to perform the synchronization and export tasks of their > > > applications. > > > > > > 19 March 2008 > > > Conduit team > > > > > _______________________________________________ > > > Conduit-list mailing list > > > Conduit-list@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/conduit-list > > > > > > _______________________________________________ > > Conduit-list mailing list > > Conduit-list@gnome.org > > > > > > http://mail.gnome.org/mailman/listinfo/conduit-list > > From Jijun.Yu@Sun.COM Fri Mar 21 01:47:45 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 176F075008B for ; Fri, 21 Mar 2008 01:47:45 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, L_P0F_Unix=-1, UNPARSEABLE_RELAY=0.001] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 19, link: ethernet/modem), [192.18.19.6] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsqqLiij4AfS for ; Fri, 21 Mar 2008 01:47:36 +0000 (GMT) Received: from sineb-mail-1.sun.com (sineb-mail-1.sun.com [192.18.19.6]) by menubar.gnome.org (Postfix) with ESMTP id CAFEE7500AF for ; Fri, 21 Mar 2008 01:47:35 +0000 (GMT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2L1lgJM015718 for ; Fri, 21 Mar 2008 01:47:42 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JY2004014U4YU00@mail-apac.sun.com> (original mail from Jijun.Yu@Sun.COM) for conduit-list@gnome.org; Fri, 21 Mar 2008 09:47:31 +0800 (SGT) Received: from [192.168.0.101] ([125.33.161.180]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JY200J544Z2E7PY@mail-apac.sun.com>; Fri, 21 Mar 2008 09:47:31 +0800 (SGT) Date: Fri, 21 Mar 2008 09:48:15 +0800 From: jijun yu Subject: Re: ANNOUNCE: Conduit 0.3.9 In-reply-to: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> Sender: Jijun.Yu@Sun.COM To: John Stowers Message-id: <47E313DF.4060301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 01:47:45 -0000 For box.net, it seems that a browser applet should be loaded and have the user log in to authorize the application every time one start Coduit and to do sync. But for me, there's no such browser applet loaded? Why? Anything I missed or should I do some configuration for? Thanks, Jerry John Stowers wrote: > Hey Everyone! > > I am proud to announce that Conduit 0.3.9 is now available for download from: > * http://download.gnome.org/sources/conduit/0.3/ > > What is it? > =========== > Conduit is a synchronization application for GNOME. It allows you to > synchronize your files, photos, emails, contacts, notes, calendar data > and any other type of personal information and synchronize that data > with another computer, an online service, or even another electronic > device. > > Conduit manages the synchronization and conversion of data into other formats. > For example, Conduit allows you to; > * Synchronize your Tomboy notes with another computer > * Synchronize your your PIM data to your mobile phone, iPod, > Nokia Internet tablet, or between computers > * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your iPod, > * ... and many more > > Any combination you can imagine, Conduit will take care of the conversion > and synchronization. > > Where can I find out more? > ========================== > * Website: http://www.conduit-project.org/ > * Screenshots/Screencast: http://www.conduit-project.org/wiki/Screenshots > * Mailing List: http://mail.gnome.org/mailman/listinfo/conduit-list > * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=conduit > > What's New? > =========== > * Add Conduit documentation (Brent Gueth) > * You can now specify your own labels when saving emails > * Removed the build dependency on dbus, just check for python-dbus > 0.80.0 > * Restore the expanded columns in the data provider pane > * Improved removable volume support (like USB keys). Now, inserting a USB > key that has been synchronized on another computer will automatically create > a preconfigured dataprovider for synchronizing the folders of interest. > > Bugs Fixed: > =========== > * Fixed #510124, Cant cancel sync without closing conduit (John Stowers) > * Fixed #511691, Improve removable folder support (John Stowers) > * Fixed #512230, 'Folder' should display as folder_name (John Stowers) > * Fixed #515328, There is NO documentation (Brent Gueth) > * Fixed #518592, Get rid of .conduit and follow fd.o specifications > (John Stowers) > * Fixed #518704, Youtube download doesnt work for old videos (Thomas > Van Machelen) > * Fixed #519708, TomboyModole says note with unicode characters in > title has disappeared (Thomas Van Machelen) > * Fixed #521194, Add "caption" support to Photos/Images (Matt Brown) > * Fixed #521349, Sync icons in status bar keep 'turning around' > (Thomas Van Machelen) > * Fixed #522436, Conduit fails to sync files with special character % > in filename (John Stowers) > > Translations: > ============= > * Updated fr: Stéphane Raimbault > * Updated pt_BR: Leonardo Ferreira Fontenelle > * Updated pt: Duarte Loreto > * Updated ca: Gil Forcada > * Updated it: Luca Ferretti > * Updated sv: Daniel Nylander > * Updated es: Jorge Gonzalez > * Updated nb: Kjartan Maraas > * Updated en_GB: Philip Withnall > > Manual Translations: > ==================== > * Updated es: John Stowers > > What Can Conduit Do: > ==================== > For a list of all the services that conduit supports see > * http://www.conduit-project.org/wiki/SyncStatus > > Conduit can perform one-way and two-synchronization (and conversion/transcoding) > of data between locations. In one-way sync/export conduit will only replace > exising data if the new copy has been modified. It can also optionally delete > data if the original has been deleted. > > Conduit has a complete DBus interface to allow other application authors to > use Conduit to perform the synchronization and export tasks of their > applications. > > 19 March 2008 > Conduit team > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > From john.stowers@gmail.com Fri Mar 21 02:43:10 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E8F275008B for ; Fri, 21 Mar 2008 02:43:10 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 1276 hrs), (distance 13, link: (Google 2)), [209.85.200.169] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03x+8Yz+ax9N for ; Fri, 21 Mar 2008 02:43:04 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by menubar.gnome.org (Postfix) with ESMTP id F39587500CA for ; Fri, 21 Mar 2008 02:43:03 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so1221941wfa.9 for ; Thu, 20 Mar 2008 19:43:02 -0700 (PDT) Received: by 10.142.171.6 with SMTP id t6mr2021888wfe.12.1206067382151; Thu, 20 Mar 2008 19:43:02 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Thu, 20 Mar 2008 19:43:02 -0700 (PDT) Message-ID: <7e40b04b0803201943y219dfdbbwf8bc3482e4306bfb@mail.gmail.com> Date: Fri, 21 Mar 2008 15:43:02 +1300 From: "John Stowers" To: "jijun yu" Subject: Re: ANNOUNCE: Conduit 0.3.9 In-Reply-To: <47E313DF.4060301@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> <47E313DF.4060301@sun.com> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 02:43:10 -0000 On Fri, Mar 21, 2008 at 2:48 PM, jijun yu wrote: > For box.net, it seems that a browser applet should be loaded and have > the user log in to authorize the application every time one start Coduit > and to do sync. > But for me, there's no such browser applet loaded? Why? Anything I > missed or should I do some configuration for? Have you got "use built in web browser" checked in conduit preferences? John > > Thanks, > Jerry > > John Stowers wrote: > > > > Hey Everyone! > > > > I am proud to announce that Conduit 0.3.9 is now available for downloa= d from: > > * http://download.gnome.org/sources/conduit/0.3/ > > > > What is it? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Conduit is a synchronization application for GNOME. It allows you to > > synchronize your files, photos, emails, contacts, notes, calendar data > > and any other type of personal information and synchronize that data > > with another computer, an online service, or even another electronic > > device. > > > > Conduit manages the synchronization and conversion of data into other = formats. > > For example, Conduit allows you to; > > * Synchronize your Tomboy notes with another computer > > * Synchronize your your PIM data to your mobile phone, iPod, > > Nokia Internet tablet, or between computers > > * Upload photos to Flickr, Picasa, SmugMug, ShutterFly and your iPod, > > * ... and many more > > > > Any combination you can imagine, Conduit will take care of the convers= ion > > and synchronization. > > > > Where can I find out more? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > * Website: http://www.conduit-project.org/ > > * Screenshots/Screencast: http://www.conduit-project.org/wiki/Screens= hots > > * Mailing List: http://mail.gnome.org/mailman/listinfo/conduit-list > > * Bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=3Dconduit > > > > What's New? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Add Conduit documentation (Brent Gueth) > > * You can now specify your own labels when saving emails > > * Removed the build dependency on dbus, just check for python-dbus > 0= .80.0 > > * Restore the expanded columns in the data provider pane > > * Improved removable volume support (like USB keys). Now, inserting a = USB > > key that has been synchronized on another computer will automaticall= y create > > a preconfigured dataprovider for synchronizing the folders of intere= st. > > > > Bugs Fixed: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Fixed #510124, Cant cancel sync without closing conduit (John Stower= s) > > * Fixed #511691, Improve removable folder support (John Stowers) > > * Fixed #512230, 'Folder' should display as folder_name (John Stowers) > > * Fixed #515328, There is NO documentation (Brent Gueth) > > * Fixed #518592, Get rid of .conduit and follow fd.o specifications > > (John Stowers) > > * Fixed #518704, Youtube download doesnt work for old videos (Thomas > > Van Machelen) > > * Fixed #519708, TomboyModole says note with unicode characters in > > title has disappeared (Thomas Van Machelen) > > * Fixed #521194, Add "caption" support to Photos/Images (Matt Brown) > > * Fixed #521349, Sync icons in status bar keep 'turning around' > > (Thomas Van Machelen) > > * Fixed #522436, Conduit fails to sync files with special character % > > in filename (John Stowers) > > > > Translations: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Updated fr: St=E9phane Raimbault > > * Updated pt_BR: Leonardo Ferreira Fontenelle > > * Updated pt: Duarte Loreto > > * Updated ca: Gil Forcada > > * Updated it: Luca Ferretti > > * Updated sv: Daniel Nylander > > * Updated es: Jorge Gonzalez > > * Updated nb: Kjartan Maraas > > * Updated en_GB: Philip Withnall > > > > Manual Translations: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Updated es: John Stowers > > > > What Can Conduit Do: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > For a list of all the services that conduit supports see > > * http://www.conduit-project.org/wiki/SyncStatus > > > > Conduit can perform one-way and two-synchronization (and conversion/tr= anscoding) > > of data between locations. In one-way sync/export conduit will only re= place > > exising data if the new copy has been modified. It can also optionally= delete > > data if the original has been deleted. > > > > Conduit has a complete DBus interface to allow other application autho= rs to > > use Conduit to perform the synchronization and export tasks of their > > applications. > > > > 19 March 2008 > > Conduit team > > > _______________________________________________ > > Conduit-list mailing list > > Conduit-list@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/conduit-list > > > > > From Jijun.Yu@Sun.COM Fri Mar 21 06:30:02 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C37D97500AF for ; Fri, 21 Mar 2008 06:30:02 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=2 tests=[AWL=0.333, BAYES_00=-2.599, L_P0F_Unix=-1, UNPARSEABLE_RELAY=0.001] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 19, link: ethernet/modem), [192.18.19.7] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Mm1pXjqu7dS for ; Fri, 21 Mar 2008 06:29:56 +0000 (GMT) Received: from sineb-mail-2.sun.com (sineb-mail-2.sun.com [192.18.19.7]) by menubar.gnome.org (Postfix) with ESMTP id DA9F67500AE for ; Fri, 21 Mar 2008 06:29:55 +0000 (GMT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2L6UFih024676 for ; Fri, 21 Mar 2008 06:30:15 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JY200J01HYTTT00@mail-apac.sun.com> (original mail from Jijun.Yu@Sun.COM) for conduit-list@gnome.org; Fri, 21 Mar 2008 14:29:41 +0800 (SGT) Received: from [129.158.217.211] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JY200BG6I1BMHVA@mail-apac.sun.com>; Fri, 21 Mar 2008 14:29:40 +0800 (SGT) Date: Fri, 21 Mar 2008 14:29:24 +0800 From: jijun yu Subject: Re: ANNOUNCE: Conduit 0.3.9 In-reply-to: <7e40b04b0803201943y219dfdbbwf8bc3482e4306bfb@mail.gmail.com> Sender: Jijun.Yu@Sun.COM To: John Stowers Message-id: <47E355C4.9050806@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> <47E313DF.4060301@sun.com> <7e40b04b0803201943y219dfdbbwf8bc3482e4306bfb@mail.gmail.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 06:30:03 -0000 John Stowers wrote: > On Fri, Mar 21, 2008 at 2:48 PM, jijun yu wrote: > >> For box.net, it seems that a browser applet should be loaded and have >> the user log in to authorize the application every time one start Coduit >> and to do sync. >> But for me, there's no such browser applet loaded? Why? Anything I >> missed or should I do some configuration for? >> > > Have you got "use built in web browser" checked in conduit preferences? > Yes. I have checked it. Thank , Jerry From john.stowers@gmail.com Fri Mar 21 06:37:28 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 28CEC75002F for ; Fri, 21 Mar 2008 06:37:28 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GT=0.077, TW_TK=0.077, TW_YG=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 1315 hrs), (distance 13, link: (Google 2)), [209.85.200.172] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G40IoXlvYlMM for ; Fri, 21 Mar 2008 06:37:23 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by menubar.gnome.org (Postfix) with ESMTP id 26AD0750008 for ; Fri, 21 Mar 2008 06:37:22 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so1296687wfa.9 for ; Thu, 20 Mar 2008 23:37:21 -0700 (PDT) Received: by 10.142.221.19 with SMTP id t19mr2110041wfg.62.1206081441677; Thu, 20 Mar 2008 23:37:21 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Thu, 20 Mar 2008 23:37:21 -0700 (PDT) Message-ID: <7e40b04b0803202337h5398ebeehf51532602a996bce@mail.gmail.com> Date: Fri, 21 Mar 2008 19:37:21 +1300 From: "John Stowers" To: "jijun yu" Subject: Re: ANNOUNCE: Conduit 0.3.9 In-Reply-To: <47E355C4.9050806@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> <47E313DF.4060301@sun.com> <7e40b04b0803201943y219dfdbbwf8bc3482e4306bfb@mail.gmail.com> <47E355C4.9050806@sun.com> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 06:37:28 -0000 On Fri, Mar 21, 2008 at 7:29 PM, jijun yu wrote: > John Stowers wrote: > > On Fri, Mar 21, 2008 at 2:48 PM, jijun yu wrote: > > > >> For box.net, it seems that a browser applet should be loaded and have > >> the user log in to authorize the application every time one start Coduit > >> and to do sync. > >> But for me, there's no such browser applet loaded? Why? Anything I > >> missed or should I do some configuration for? > >> > > > > Have you got "use built in web browser" checked in conduit preferences? > > > Yes. I have checked it. > > Thank , > Jerry > > Ok, things to try, 1) Do you have pygtkmozembed installed? (gnome-python-extras in debian based distros) 1b) What happens when you run python -c 'import gtkmozembed' in a terminal? 2) What happens when you run python scripts/CheckGtkMozEmbed.py In a terminal (i.e if it crashes, that is bad) 3) When you launch conduit from a terminal, do you get a warning like this at the start "WARNING: COULD NOT FIND FIREFOX LIBRARIES" "WARNING: CONDUIT MAY CRASH UNEXPECTEDLY" "WARNING: PLEASE TALK TO THE PERSON WHO PACKAGED CONDUIT" John From Irene.Huang@Sun.COM Fri Mar 21 09:08:20 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5B3657500AF for ; Fri, 21 Mar 2008 09:08:20 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=2 tests=[AWL=0.553, BAYES_00=-2.599, L_P0F_Unix=-1, UNPARSEABLE_RELAY=0.001] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 19, link: ethernet/modem), [192.18.19.6] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3+7XKtqZ8GG for ; Fri, 21 Mar 2008 09:08:15 +0000 (GMT) Received: from sineb-mail-1.sun.com (sineb-mail-1.sun.com [192.18.19.6]) by menubar.gnome.org (Postfix) with ESMTP id 20A8D7500AE for ; Fri, 21 Mar 2008 09:08:14 +0000 (GMT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2L98LXe008218 for ; Fri, 21 Mar 2008 09:08:21 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JY200K01P37H100@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM) for conduit-list@gnome.org; Fri, 21 Mar 2008 17:08:01 +0800 (SGT) Received: from [129.158.217.138] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JY200B6MPDAMFIZ@mail-apac.sun.com> for conduit-list@gnome.org; Fri, 21 Mar 2008 17:07:59 +0800 (SGT) Date: Fri, 21 Mar 2008 17:08:36 +0800 From: Irene Huang Subject: HELP: is there a way to set proxy for Conduit? Sender: Irene.Huang@Sun.COM To: conduit-list@gnome.org Message-id: <1206090516.2611.2.camel@goalie> MIME-version: 1.0 X-Mailer: Evolution 2.21.92 Content-type: text/plain Content-transfer-encoding: 7BIT X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 09:08:20 -0000 hi, Conduit developers :) I am using conduit within an intranet which requires proxy to access internet. I am wondering if there's a way to get Conduit use the system proxy, or to set a proxy for conduit's own use somehow? Thanks in advance. --Irene From Jijun.Yu@Sun.COM Fri Mar 21 09:10:35 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 26FF4750092 for ; Fri, 21 Mar 2008 09:10:35 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=2 tests=[AWL=0.206, BAYES_00=-2.599, L_P0F_Unix=-1, TW_GT=0.077, TW_TK=0.077, TW_YG=0.077, UNPARSEABLE_RELAY=0.001] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 19, link: ethernet/modem), [192.18.19.6] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9svHfFuAHjqA for ; Fri, 21 Mar 2008 09:10:26 +0000 (GMT) Received: from sineb-mail-1.sun.com (sineb-mail-1.sun.com [192.18.19.6]) by menubar.gnome.org (Postfix) with ESMTP id D6F9B750008 for ; Fri, 21 Mar 2008 09:10:25 +0000 (GMT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2L9AWSw008334 for ; Fri, 21 Mar 2008 09:10:32 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JY200201PGP0200@mail-apac.sun.com> (original mail from Jijun.Yu@Sun.COM) for conduit-list@gnome.org; Fri, 21 Mar 2008 17:10:12 +0800 (SGT) Received: from [129.158.217.211] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JY200BAXPGZMFIZ@mail-apac.sun.com>; Fri, 21 Mar 2008 17:10:11 +0800 (SGT) Date: Fri, 21 Mar 2008 17:09:59 +0800 From: jijun yu Subject: Re: ANNOUNCE: Conduit 0.3.9 In-reply-to: <7e40b04b0803202337h5398ebeehf51532602a996bce@mail.gmail.com> Sender: Jijun.Yu@Sun.COM To: John Stowers Message-id: <47E37B67.4050208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <7e40b04b0803190231q65bba131y94d3ce65a1c9f83@mail.gmail.com> <47E313DF.4060301@sun.com> <7e40b04b0803201943y219dfdbbwf8bc3482e4306bfb@mail.gmail.com> <47E355C4.9050806@sun.com> <7e40b04b0803202337h5398ebeehf51532602a996bce@mail.gmail.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 09:10:35 -0000 John Stowers wrote: > On Fri, Mar 21, 2008 at 7:29 PM, jijun yu wrote: > >> John Stowers wrote: >> > On Fri, Mar 21, 2008 at 2:48 PM, jijun yu wrote: >> > >> >> For box.net, it seems that a browser applet should be loaded and have >> >> the user log in to authorize the application every time one start Coduit >> >> and to do sync. >> >> But for me, there's no such browser applet loaded? Why? Anything I >> >> missed or should I do some configuration for? >> >> >> > >> > Have you got "use built in web browser" checked in conduit preferences? >> > >> Yes. I have checked it. >> >> Thank , >> Jerry >> >> >> > > Ok, things to try, > 1) Do you have pygtkmozembed installed? (gnome-python-extras in debian > based distros) > 1b) What happens when you run > python -c 'import gtkmozembed' > in a terminal? > 2) What happens when you run > python scripts/CheckGtkMozEmbed.py > In a terminal (i.e if it crashes, that is bad) > 3) When you launch conduit from a terminal, do you get a warning like > this at the start > > "WARNING: COULD NOT FIND FIREFOX LIBRARIES" > "WARNING: CONDUIT MAY CRASH UNEXPECTEDLY" > "WARNING: PLEASE TALK TO THE PERSON WHO PACKAGED CONDUIT" > After installed the modules as you said above, the browser applet can be loaded now and refreshing box.net is also ok, thought I tried several times. But during the synchronization, there's nothing happed. Don't know the reason. As I'm in the intranet of my company, should I set the proxy for conduit. If yes, how to set? Thanks, Jerry From shaunbarlowmusic@gmail.com Mon Mar 24 04:34:41 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D3023750071 for ; Mon, 24 Mar 2008 04:34:41 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=2 tests=[BAYES_20=-0.74, HTML_10_20=1.351, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 2014 hrs), (distance 12, link: (Google 2)), [209.85.200.173] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkkhF2sgAGID for ; Mon, 24 Mar 2008 04:34:39 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by menubar.gnome.org (Postfix) with ESMTP id 4E6957500A9 for ; Mon, 24 Mar 2008 04:34:39 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so2580923wfa.9 for ; Sun, 23 Mar 2008 21:34:37 -0700 (PDT) Received: by 10.142.222.21 with SMTP id u21mr4111040wfg.231.1206333277951; Sun, 23 Mar 2008 21:34:37 -0700 (PDT) Received: by 10.142.178.9 with HTTP; Sun, 23 Mar 2008 21:34:37 -0700 (PDT) Message-ID: Date: Mon, 24 Mar 2008 15:34:37 +1100 From: "Shaun Barlow" To: conduit-list@gnome.org Subject: ppa not updated with 0.3.9 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11978_1213768.1206333277941" X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 04:34:42 -0000 ------=_Part_11978_1213768.1206333277941 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey guys, It's been a while since you released 0.3.9 but it's not in the ppa yet. I have compiled things before, am pretty much a novice, but I'd help out and do it if someone points me in the right direction of a how to or something. If not then i guess this is a bump for the ppa update. Cheers all, Shaun ------=_Part_11978_1213768.1206333277941 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey guys,
It's been a while since you released 0.3.9 but it's not in the ppa yet.
I have compiled things before, am pretty much a novice, but I'd help out and do it if someone points me in the right direction of a how to or something.
If not then i guess this is a bump for the ppa update.
Cheers all,
Shaun

------=_Part_11978_1213768.1206333277941-- From john.m.carr@gmail.com Mon Mar 24 05:55:51 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 32CD47500A9 for ; Mon, 24 Mar 2008 05:55:51 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 5689 hrs), (distance 12, link: (Google 2)), [64.233.166.180] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOFpk4u2cwdY for ; Mon, 24 Mar 2008 05:55:48 +0000 (GMT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by menubar.gnome.org (Postfix) with ESMTP id 162A5750071 for ; Mon, 24 Mar 2008 05:55:47 +0000 (GMT) Received: by py-out-1112.google.com with SMTP id w49so6828896pyg.36 for ; Sun, 23 Mar 2008 22:55:46 -0700 (PDT) Received: by 10.114.26.18 with SMTP id 18mr10797798waz.130.1206338146332; Sun, 23 Mar 2008 22:55:46 -0700 (PDT) Received: by 10.114.168.2 with HTTP; Sun, 23 Mar 2008 22:55:46 -0700 (PDT) Message-ID: <860b49b30803232255w36b673a0v5634c04ae2fded78@mail.gmail.com> Date: Mon, 24 Mar 2008 05:55:46 +0000 From: "John Carr" Sender: john.m.carr@gmail.com To: "Shaun Barlow" Subject: Re: ppa not updated with 0.3.9 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 33dc6aee3c14f321 Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 05:55:51 -0000 Hey Shaun I can only update the PPA from a PC that I won't have access to until tomorrow (had real troubles getting autoppa going on hardy, which its not even packaged for). Don't worry though, it will be done. John 2008/3/24 Shaun Barlow : > Hey guys, > It's been a while since you released 0.3.9 but it's not in the ppa yet. > I have compiled things before, am pretty much a novice, but I'd help out and > do it if someone points me in the right direction of a how to or something. > If not then i guess this is a bump for the ppa update. > Cheers all, > Shaun From shaunbarlowmusic@gmail.com Mon Mar 24 06:32:02 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2181E750071 for ; Mon, 24 Mar 2008 06:32:02 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 2053 hrs), (distance 16, link: (Google 2)), [72.14.220.152] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rimjD-LNymvP for ; Mon, 24 Mar 2008 06:31:58 +0000 (GMT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by menubar.gnome.org (Postfix) with ESMTP id 475B6750078 for ; Mon, 24 Mar 2008 06:31:57 +0000 (GMT) Received: by fg-out-1718.google.com with SMTP id d23so2272536fga.33 for ; Sun, 23 Mar 2008 23:31:56 -0700 (PDT) Received: by 10.78.189.5 with SMTP id m5mr19412787huf.77.1206340316166; Sun, 23 Mar 2008 23:31:56 -0700 (PDT) Received: by 10.78.196.20 with HTTP; Sun, 23 Mar 2008 23:31:56 -0700 (PDT) Message-ID: Date: Mon, 24 Mar 2008 17:31:56 +1100 From: "Shaun Barlow" To: "John Carr" Subject: Re: ppa not updated with 0.3.9 In-Reply-To: <860b49b30803232255w36b673a0v5634c04ae2fded78@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6452_7646845.1206340316154" References: <860b49b30803232255w36b673a0v5634c04ae2fded78@mail.gmail.com> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 06:32:02 -0000 ------=_Part_6452_7646845.1206340316154 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline No sweat. Thanks man On Mon, Mar 24, 2008 at 4:55 PM, John Carr wrote: > Hey Shaun > > I can only update the PPA from a PC that I won't have access to until > tomorrow (had real troubles getting autoppa going on hardy, which its > not even packaged for). Don't worry though, it will be done. > > John > > 2008/3/24 Shaun Barlow : > > Hey guys, > > It's been a while since you released 0.3.9 but it's not in the ppa yet. > > I have compiled things before, am pretty much a novice, but I'd help out > and > > do it if someone points me in the right direction of a how to or > something. > > If not then i guess this is a bump for the ppa update. > > Cheers all, > > Shaun > ------=_Part_6452_7646845.1206340316154 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline No sweat.
Thanks man

On Mon, Mar 24, 2008 at 4:55 PM, John Carr <john.carr@unrouted.co.uk> wrote:
Hey Shaun

I can only update the PPA from a PC that I won't have access to until
tomorrow (had real troubles getting autoppa going on hardy, which its
not even packaged for). Don't worry though, it will be done.

John

2008/3/24 Shaun Barlow <shaunbarlowmusic@gmail.com>:
> Hey guys,
> It's been a while since you released 0.3.9 but it's not in the ppa yet.
> I have compiled things before, am pretty much a novice, but I'd help out and
> do it if someone points me in the right direction of a how to or something.
>  If not then i guess this is a bump for the ppa update.
> Cheers all,
> Shaun

------=_Part_6452_7646845.1206340316154-- From bernhard.gehl@gmx.net Mon Mar 24 14:32:21 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D5EFF7501DB for ; Mon, 24 Mar 2008 14:32:21 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=2 tests=[BAYES_50=0.001] X-Amavis-OS-Fingerprint: Linux 2.6, seldom 2.4 (older, 4) (up: 1510 hrs), (distance 22, link: ethernet/modem), [213.165.64.20] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6gBghP2YFV8 for ; Mon, 24 Mar 2008 14:32:19 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 19F78750215 for ; Mon, 24 Mar 2008 14:32:18 +0000 (GMT) Received: (qmail invoked by alias); 24 Mar 2008 14:32:16 -0000 Received: from stgt-4d021105.pool.mediaWays.net (EHLO [192.168.1.6]) [77.2.17.5] by mail.gmx.net (mp051) with SMTP; 24 Mar 2008 15:32:16 +0100 X-Authenticated: #154581 X-Provags-ID: V01U2FsdGVkX18xJXYWD+4xMWWsm91QtxH+jJPz/nrgLmtFU/JH5K hPKrHJ46rt1PCy Subject: Sync getting stuck with google calendar From: Bernhard Gehl To: conduit-list@gnome.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JtY6z4nv9mRyM4x7DHGG" Date: Mon, 24 Mar 2008 15:31:15 +0100 Message-Id: <1206369075.311.3.camel@Magnesium> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Tue, 25 Mar 2008 10:21:44 +0000 X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 14:32:22 -0000 --=-JtY6z4nv9mRyM4x7DHGG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi there, well, it seems I keep running into some problem that obviously doesn't occur to anyone else: my conduit google-evolution-calendar sync keeps stopping at "11%" as soon as I switch it to two way. The debugging output (command line) tells me of an "AttributeError: 'GoogleEvent' object has no attribute 'get_UID'". Is this a google problem and if yes, can it be fixed by some workaround? Thanks for any help, Bernhard --=-JtY6z4nv9mRyM4x7DHGG Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG/WinPT-Installer - http://www.equipmente.de iD8DBQBH57szIzWBdD1rq+8RArEfAKDJk1DizRFGm8w2phvccLYRYEetAACghtws FNmzoYs1Uwo16qnN7VxCUlw= =TL9r -----END PGP SIGNATURE----- --=-JtY6z4nv9mRyM4x7DHGG-- From roumano@gmail.com Tue Mar 25 14:15:14 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7C28275008A for ; Tue, 25 Mar 2008 14:15:14 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 10018 hrs), (distance 12, link: (Google 2)), [209.85.198.191] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnqYrSHz885L for ; Tue, 25 Mar 2008 14:15:07 +0000 (GMT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by menubar.gnome.org (Postfix) with ESMTP id 1911C75017F for ; Tue, 25 Mar 2008 14:15:03 +0000 (GMT) Received: by rv-out-0910.google.com with SMTP id k20so1663543rvb.3 for ; Tue, 25 Mar 2008 07:15:02 -0700 (PDT) Received: by 10.140.201.1 with SMTP id y1mr3329928rvf.246.1206454502122; Tue, 25 Mar 2008 07:15:02 -0700 (PDT) Received: by 10.141.107.20 with HTTP; Tue, 25 Mar 2008 07:15:02 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 15:15:02 +0100 From: "Roumano :)" To: conduit-list@gnome.org Subject: Sync getting stuck with google calendar MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 14:15:14 -0000 > > Today's Topics: > > 1. Sync getting stuck with google calendar (Bernhard Gehl) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 24 Mar 2008 15:31:15 +0100 > From: Bernhard Gehl > Subject: Sync getting stuck with google calendar > To: conduit-list@gnome.org > Message-ID: <1206369075.311.3.camel@Magnesium> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi there, > > well, it seems I keep running into some problem that obviously doesn't > occur to anyone else: my conduit google-evolution-calendar sync keeps > stopping at "11%" as soon as I switch it to two way. The debugging > output (command line) tells me of an "AttributeError: 'GoogleEvent' > object has no attribute 'get_UID'". > > Is this a google problem and if yes, can it be fixed by some workaround? Yes it will be cool. A bug is already open : Bug 517903 =96 Error sync-ing between googlecal and evolution From john.stowers@gmail.com Wed Mar 26 08:24:24 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C989B75017E for ; Wed, 26 Mar 2008 08:24:24 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 2532 hrs), (distance 14, link: (Google 2)), [209.85.200.173] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+7bzULJCqsY for ; Wed, 26 Mar 2008 08:24:20 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by menubar.gnome.org (Postfix) with ESMTP id 5E6EB750065 for ; Wed, 26 Mar 2008 08:24:20 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so2943844wfa.9 for ; Wed, 26 Mar 2008 01:24:19 -0700 (PDT) Received: by 10.142.211.10 with SMTP id j10mr4882405wfg.168.1206519859015; Wed, 26 Mar 2008 01:24:19 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Wed, 26 Mar 2008 01:24:18 -0700 (PDT) Message-ID: <7e40b04b0803260124w7e507f89ieb0253b5c1aa63c4@mail.gmail.com> Date: Wed, 26 Mar 2008 21:24:18 +1300 From: "John Stowers" To: "Irene Huang" Subject: Re: HELP: is there a way to set proxy for Conduit? In-Reply-To: <1206090516.2611.2.camel@goalie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1206090516.2611.2.camel@goalie> Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 08:24:25 -0000 On Fri, Mar 21, 2008 at 10:08 PM, Irene Huang wrote: > hi, Conduit developers :) > > I am using conduit within an intranet which requires proxy to access > internet. I am wondering if there's a way to get Conduit use the system > proxy, or to set a proxy for conduit's own use somehow? Unfortunately not, I will be adding this functionality in the coming cycle. Please subscribe to http://bugzilla.gnome.org/show_bug.cgi?id=514649 John > > Thanks in advance. > > --Irene > > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > From Jijun.Yu@Sun.COM Wed Mar 26 08:48:53 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6199D75017E for ; Wed, 26 Mar 2008 08:48:53 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=2 tests=[AWL=0.315, BAYES_00=-2.599, L_P0F_Unix=-1, UNPARSEABLE_RELAY=0.001] X-Amavis-OS-Fingerprint: Solaris 10 (beta), (distance 19, link: ethernet/modem), [192.18.19.6] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJATzqcMoLZ5 for ; Wed, 26 Mar 2008 08:48:46 +0000 (GMT) Received: from sineb-mail-1.sun.com (sineb-mail-1.sun.com [192.18.19.6]) by menubar.gnome.org (Postfix) with ESMTP id 7DC7F750065 for ; Wed, 26 Mar 2008 08:48:45 +0000 (GMT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2Q8mnsR025820 for ; Wed, 26 Mar 2008 08:48:49 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JYB00D01XQ09400@mail-apac.sun.com> (original mail from Jijun.Yu@Sun.COM) for conduit-list@gnome.org; Wed, 26 Mar 2008 16:48:36 +0800 (SGT) Received: from [129.158.217.211] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYB00JPQXT0E7Y5@mail-apac.sun.com>; Wed, 26 Mar 2008 16:48:36 +0800 (SGT) Date: Wed, 26 Mar 2008 16:48:11 +0800 From: jijun yu Subject: Re: HELP: is there a way to set proxy for Conduit? In-reply-to: <7e40b04b0803260124w7e507f89ieb0253b5c1aa63c4@mail.gmail.com> Sender: Jijun.Yu@Sun.COM To: John Stowers Message-id: <47EA0DCB.30305@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <1206090516.2611.2.camel@goalie> <7e40b04b0803260124w7e507f89ieb0253b5c1aa63c4@mail.gmail.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Cc: conduit-list@gnome.org, Irene Huang X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 08:48:53 -0000 John Stowers wrote: > On Fri, Mar 21, 2008 at 10:08 PM, Irene Huang wrote: > >> hi, Conduit developers :) >> >> I am using conduit within an intranet which requires proxy to access >> internet. I am wondering if there's a way to get Conduit use the system >> proxy, or to set a proxy for conduit's own use somehow? >> > > Unfortunately not, I will be adding this functionality in the coming > cycle. Please subscribe to > > http://bugzilla.gnome.org/show_bug.cgi?id=514649 > It will be great. I have subscribed this bug. Regards, Jerry > John > > >> Thanks in advance. >> >> --Irene >> >> _______________________________________________ >> Conduit-list mailing list >> Conduit-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/conduit-list >> >> > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > From john.stowers@gmail.com Wed Mar 26 09:16:04 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E90CC750303 for ; Wed, 26 Mar 2008 09:16:03 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 2541 hrs), (distance 13, link: (Google 2)), [209.85.200.172] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcM4pk1BZ7hf for ; Wed, 26 Mar 2008 09:15:58 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by menubar.gnome.org (Postfix) with ESMTP id C3475750167 for ; Wed, 26 Mar 2008 09:15:58 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so2961531wfa.9 for ; Wed, 26 Mar 2008 02:15:57 -0700 (PDT) Received: by 10.142.107.1 with SMTP id f1mr4916138wfc.10.1206522957278; Wed, 26 Mar 2008 02:15:57 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Wed, 26 Mar 2008 02:15:57 -0700 (PDT) Message-ID: <7e40b04b0803260215yc7f3adblaee76609ccadef8f@mail.gmail.com> Date: Wed, 26 Mar 2008 22:15:57 +1300 From: "John Stowers" To: Conduit Subject: Heads UP: API Change MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 09:16:04 -0000 Hey, Thanks to the wonderful work of Claude Paroz, conduit/Utils.py has been moved to its own module, conduit.utils as per http://bugzilla.gnome.org/show_bug.cgi?id=520748 If you were previously using conduit.Utils functions the following changes will need to be made import conduit.Utils as Utils --> import conduit.utils as Utils Thanks John From john.stowers@gmail.com Fri Mar 28 18:46:22 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1EE0B75094D for ; Fri, 28 Mar 2008 18:46:22 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc4UZltDrsFW for ; Fri, 28 Mar 2008 18:46:08 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by menubar.gnome.org (Postfix) with ESMTP id F1373751B3C for ; Fri, 28 Mar 2008 12:12:08 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so205228wfa.9 for ; Fri, 28 Mar 2008 05:12:06 -0700 (PDT) Received: by 10.143.37.20 with SMTP id p20mr1962230wfj.236.1206706326890; Fri, 28 Mar 2008 05:12:06 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Fri, 28 Mar 2008 05:12:06 -0700 (PDT) Message-ID: <7e40b04b0803280512q4c479282r890363d933204472@mail.gmail.com> Date: Sat, 29 Mar 2008 01:12:06 +1300 From: "John Stowers" To: Conduit Subject: Remember the Milk MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 18:46:22 -0000 Hey Guys, Is anyone currently working on a dataprovider for remember the milk? John From web.kiddo@free.fr Sat Mar 29 20:25:39 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4ADFE7500BC for ; Sat, 29 Mar 2008 20:25:39 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.937 X-Spam-Level: X-Spam-Status: No, score=0.937 tagged_above=-999 required=2 tests=[BAYES_50=0.001, FORGED_RCVD_HELO=0.135, HTML_MESSAGE=0.001, L_P0F_UNKN=0.8] X-Amavis-OS-Fingerprint: UNKNOWN [16384:48:1:48:M1460,S,E:P:?:?], (link: ethernet/modem), [206.248.154.182] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkqnXEr9gmSN for ; Sat, 29 Mar 2008 20:25:35 +0000 (GMT) Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by menubar.gnome.org (Postfix) with ESMTP id 3A934750107 for ; Sat, 29 Mar 2008 20:25:34 +0000 (GMT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowHAHpC7kfO+Ktx/2dsb2JhbACBWmI2pj8 X-IronPort-AV: E=Sophos;i="4.25,576,1199682000"; d="scan'208,217";a="17134997" Received: from mail.pppoe.ca (HELO mail.teksavvy.com) ([65.39.192.132]) by ironport2-out.teksavvy.com with ESMTP; 29 Mar 2008 16:25:33 -0400 Received: from [192.168.1.135] ([206.248.171.113]) by mail.teksavvy.com (Internet Mail Server v1.0) with ESMTP id JXC04733; Sat, 29 Mar 2008 16:25:33 -0400 Subject: Re: evolution dataproviders in 0.3.8 From: Jeff To: John Carr In-Reply-To: <860b49b30802260655s2ae123f9ocdf52bad62b14a94@mail.gmail.com> References: <1204035837.5988.4.camel@khloe> <860b49b30802260655s2ae123f9ocdf52bad62b14a94@mail.gmail.com> Content-Type: multipart/alternative; boundary="=-2Ra63Jyo6sEFXVCHMqOm" Date: Sat, 29 Mar 2008 16:25:32 -0400 Message-Id: <1206822333.10819.4.camel@khloe> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2008 20:25:39 -0000 --=-2Ra63Jyo6sEFXVCHMqOm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Le mardi 26 février 2008 à 14:55 +0000, John Carr a écrit : > The python-evolution bindings in gutsy are too old I think. The PPA is > building python-evolution 0.0.4 for lpia, i386 and amd64 as i type. If > you install those then your Conduit should show the various Evolution > bits and pieces. Hmmm. This may explain why I couldn't get calendar network syncing to work (at all) and could not get tasks network syncing working (properly) today, with a gutsy and hardy machine. I guess I will have to wait for hardy final, have it installed on both machines with the same software versions all over the place before trying again. One moment where it "almost" worked was with tasks syncing; but conduit didn't realize that they were *already* in sync to begin with, and made duplicate entries all over the place. When I tried again by having the destination computer have a blank tasks folder (I killed the evolution data server processess between each trials), it did not work at all for some reason. Syncing calendars was most unsuccessful, hanging at 6%, with no results in the end. Hopefully I'll be luckier when I try again after ubuntu 8.04 is released... --=-2Ra63Jyo6sEFXVCHMqOm Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Le mardi 26 février 2008 à 14:55 +0000, John Carr a écrit :
The python-evolution bindings in gutsy are too old I think. The PPA is
building python-evolution 0.0.4 for lpia, i386 and amd64 as i type. If
you install those then your Conduit should show the various Evolution
bits and pieces.

Hmmm. This may explain why I couldn't get calendar network syncing to work (at all) and could not get tasks network syncing working (properly) today, with a gutsy and hardy machine.

I guess I will have to wait for hardy final, have it installed on both machines with the same software versions all over the place before trying again.

One moment where it "almost" worked was with tasks syncing; but conduit didn't realize that they were *already* in sync to begin with, and made duplicate entries all over the place. When I tried again by having the destination computer have a blank tasks folder (I killed the evolution data server processess between each trials), it did not work at all for some reason.

Syncing calendars was most unsuccessful, hanging at 6%, with no results in the end.

Hopefully I'll be luckier when I try again after ubuntu 8.04 is released... --=-2Ra63Jyo6sEFXVCHMqOm-- From SRS0=aUnzp0=UQ=kubasik.net=kevin@srs.bis.na.blackberry.com Sun Mar 30 00:20:34 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3B5DE750120 for ; Sun, 30 Mar 2008 00:20:34 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: YES X-Spam-Score: 2.245 X-Spam-Level: ** X-Spam-Status: Yes, score=2.245 tagged_above=-999 required=2 tests=[BAYES_50=0.001, FORGED_RCVD_HELO=0.135, FROM_EXCESS_BASE64=1.309, L_P0F_UNKN=0.8] X-Amavis-OS-Fingerprint: UNKNOWN [16384:41:1:48:M1460,S,E:P:?:?], (link: ethernet/modem), [216.9.248.49] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSfkZ5X3MkvT for ; Sun, 30 Mar 2008 00:20:29 +0000 (GMT) Received: from smtp02.bis.na.blackberry.com (smtp02.bis.na.blackberry.com [216.9.248.49]) by menubar.gnome.org (Postfix) with ESMTP id DFEB175016A for ; Sun, 30 Mar 2008 00:20:23 +0000 (GMT) Received: from bda005.bis.na.blackberry.com (bda005.bisx.prod.on.blackberry [172.20.224.65]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m2U0KL9d024662; Sun, 30 Mar 2008 00:20:21 GMT Received: from bda005-cell00.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda005.bis.na.blackberry.com (8.13.4 TEAMON/8.13.4) with ESMTP id m2U0KIuE030310; Sun, 30 Mar 2008 00:20:18 GMT X-rim-org-msg-ref-id: 1010259389 Message-ID: <1010259389-1206836412-cardhu_decombobulator_blackberry.rim.net-300886389-@bxe120.bisx.prod.on.blackberry> X-Priority: Normal Sensitivity: Normal Importance: Normal To: "John Stowers" , "Conduit" Subject: Re: Remember the Milk From: "=?utf-8?B?S2V2aW4gS3ViYXNpaw==?=" Date: Sun, 30 Mar 2008 00:24:06 +0000 Content-Type: text/plain MIME-Version: 1.0 X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: kevin@kubasik.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2008 00:20:34 -0000 I am, its not much yet. ------Original Message------ From: John Stowers Sender: To: Conduit Sent: Mar 28, 2008 6:12 AM Subject: Remember the Milk Hey Guys, Is anyone currently working on a dataprovider for remember the milk? John _______________________________________________ Conduit-list mailing list Conduit-list@gnome.org http://mail.gnome.org/mailman/listinfo/conduit-list Sent from my Verizon Wireless BlackBerry From john.stowers@gmail.com Sun Mar 30 09:53:45 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A1CC2750183 for ; Sun, 30 Mar 2008 09:53:45 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 3507 hrs), (distance 14, link: (Google 2)), [209.85.200.168] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwpczPxhrCQA for ; Sun, 30 Mar 2008 09:53:39 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by menubar.gnome.org (Postfix) with ESMTP id D8A00750209 for ; Sun, 30 Mar 2008 09:53:38 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so973515wfa.9 for ; Sun, 30 Mar 2008 02:53:37 -0700 (PDT) Received: by 10.143.162.8 with SMTP id p8mr775781wfo.49.1206870817406; Sun, 30 Mar 2008 02:53:37 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Sun, 30 Mar 2008 02:53:37 -0700 (PDT) Message-ID: <7e40b04b0803300253q7201de2bm7617856e83106506@mail.gmail.com> Date: Sun, 30 Mar 2008 22:53:37 +1300 From: "John Stowers" To: kevin@kubasik.net Subject: Re: Remember the Milk In-Reply-To: <1010259389-1206836412-cardhu_decombobulator_blackberry.rim.net-300886389-@bxe120.bisx.prod.on.blackberry> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1010259389-1206836412-cardhu_decombobulator_blackberry.rim.net-300886389-@bxe120.bisx.prod.on.blackberry> Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2008 09:53:45 -0000 On Sun, Mar 30, 2008 at 1:24 PM, Kevin Kubasik wrote: > I am, its not much yet. OK Cool. Good to know. Please post to bugzilla when you have a chance. That way I can help you with the implementation. John > > > ------Original Message------ > From: John Stowers > Sender: > To: Conduit > Sent: Mar 28, 2008 6:12 AM > Subject: Remember the Milk > > Hey Guys, > > Is anyone currently working on a dataprovider for remember the milk? > > John > _______________________________________________ > Conduit-list mailing list > Conduit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/conduit-list > > > Sent from my Verizon Wireless BlackBerry > > From admin@kubasik.net Mon Mar 31 02:03:49 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 469FF750094 for ; Mon, 31 Mar 2008 02:03:49 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 2368 hrs), (distance 17, link: (Google 2)), [72.14.214.238] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAl9Xwpkt2AN for ; Mon, 31 Mar 2008 02:03:43 +0000 (GMT) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.238]) by menubar.gnome.org (Postfix) with ESMTP id 3F0CD7501AB for ; Mon, 31 Mar 2008 02:03:37 +0000 (GMT) Received: by hu-out-0506.google.com with SMTP id 22so4015354hug.23 for ; Sun, 30 Mar 2008 19:03:35 -0700 (PDT) Received: by 10.86.36.11 with SMTP id j11mr4087952fgj.5.1206929015454; Sun, 30 Mar 2008 19:03:35 -0700 (PDT) Received: by 10.86.4.7 with HTTP; Sun, 30 Mar 2008 19:03:35 -0700 (PDT) Message-ID: <78b1a24a0803301903y3496f224o7eaee93e2f9b405a@mail.gmail.com> Date: Sun, 30 Mar 2008 20:03:35 -0600 From: "Kevin Kubasik" Sender: admin@kubasik.net To: "John Stowers" Subject: Re: Remember the Milk In-Reply-To: <7e40b04b0803300253q7201de2bm7617856e83106506@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1010259389-1206836412-cardhu_decombobulator_blackberry.rim.net-300886389-@bxe120.bisx.prod.on.blackberry> <7e40b04b0803300253q7201de2bm7617856e83106506@mail.gmail.com> X-Google-Sender-Auth: 9ff1c459585b07d2 Cc: Conduit X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 02:03:49 -0000 Will do. I've been meaning to get it more in shape/complete, but I just haven't had the time. I hope to get around to it some time this week. Cheer, Kevin Kubasik On Sun, Mar 30, 2008 at 3:53 AM, John Stowers wrote: > On Sun, Mar 30, 2008 at 1:24 PM, Kevin Kubasik wrote: > > I am, its not much yet. > > OK Cool. Good to know. Please post to bugzilla when you have a chance. > That way I can help you with the implementation. > > John > > > > > > > > > > ------Original Message------ > > From: John Stowers > > Sender: > > To: Conduit > > Sent: Mar 28, 2008 6:12 AM > > Subject: Remember the Milk > > > > Hey Guys, > > > > Is anyone currently working on a dataprovider for remember the milk? > > > > John > > _______________________________________________ > > Conduit-list mailing list > > Conduit-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/conduit-list > > > > > > Sent from my Verizon Wireless BlackBerry > > > > > -- Kevin Kubasik http://kubasik.net/blog From john.stowers.lists@gmail.com Mon Mar 31 10:35:18 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1A13775008B for ; Mon, 31 Mar 2008 10:35:18 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_EV=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11421 hrs), (distance 14, link: (Google 2)), [209.85.198.186] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOEyZwzB3uEJ for ; Mon, 31 Mar 2008 10:35:12 +0000 (GMT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by menubar.gnome.org (Postfix) with ESMTP id 487BF750153 for ; Mon, 31 Mar 2008 10:35:11 +0000 (GMT) Received: by rv-out-0910.google.com with SMTP id k20so851838rvb.3 for ; Mon, 31 Mar 2008 03:35:10 -0700 (PDT) Received: by 10.140.177.15 with SMTP id z15mr3217124rve.128.1206959710234; Mon, 31 Mar 2008 03:35:10 -0700 (PDT) Received: from ?192.168.1.127? ( [118.90.59.226]) by mx.google.com with ESMTPS id c19sm9987990rvf.30.2008.03.31.03.35.06 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Mar 2008 03:35:08 -0700 (PDT) Subject: Module proposal: Conduit for GNOME 2.24 From: John Stowers To: desktop-devel-list@gnome.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 31 Mar 2008 23:35:27 +1300 Message-Id: <1206959727.5776.1.camel@nzjrs-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Content-Transfer-Encoding: 8bit Cc: conduit-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 10:35:18 -0000 Hey Guys, On behalf of the Conduit [1] development team, I would like to propose Conduit for inclusion in GNOME 2.24 desktop suite. * Purpose: Conduit is a synchronization architecture for the GNOME desktop. It provides an intuitive GUI for synchronizing things and a DBus interface for external applications to do the same. * Justification: Our immediate benefits to the GNOME desktop are very well supported multi-site photo/upload and sync (from Fspot, eog and folder), tomboy synchronization to a number of places, file/folder sync (including intuitive removable volume support, and the ability to do all these things peer to peer. We also support many more than these listed, however at the cost of additional dependencies. See below for clarification. In implementing these diverse backends, I am confident our abstractions are sound, and we will be able to grow with the GNOME desktop and support synchronization with any device you can imagine. Applications using our DBus interface will get these benefits at no extra cost. * Dependencies: pygtk, gnomevfs, gnome-python-desktop > 2.22, python-gtkmozembed, [NEW] pygoocanvas > 0.9.0, [NEW] goocanvas > 0.9.0,  [NEW] Python 2.5 (for network sync support) * Resource usage: GNOME FTP, GNOME SVN, GNOME bugzilla, translations * Adoption: Packaged for all major distros, expressions of interest for more extensive use by Ubuntu [2], Mandriva [3] and Suse [4] * Gnome-ness: * We support Tomboy note sync and Fspot photo sync. In both cases we were instrumental in the development of DBus interfaces in the respective applications * We support evolution-data-server through the new python evolution bindings we contributed to GNOME last cycle. * Our file/folder sync uses gnomevfs * [WIP] We have developed an eog plugin for photo upload to a number of sites, directly from within the application * [WIP] We have developed a nautilus plugin to enable easy file/folder sync * Additional Information: Our focus for this cycle is the support of mobile devices through both libsyncml [5] and (python)gammu [6]. This will obviously introduce additional dependencies on these libraries. We are looking forward to, and will be adding support for GIO/GVFS as soon as it is available to be used from Python. We also support the following services although support for them comes at the cost of additional dependencies * Google contacts, [WIP] calendar, [WIP] documents (requires python-gdata [7]) * Backpackit.com (require python backpack [8]) * Facebook photos (requires pyfacebook [9]) * iPod photos (requires libgpod [10]) Conduit is translated into a number of languages, and features user help documentation. However both of these are WIP. We have had firm expressions of interest from Tomboy and Cheese about using conduit for Sync and Export respectively. Conduits presence in the desktop set would make their dependency on us for this functionality more palatable. Looking forward to hearing your thoughts John Stowers [1] http://www.conduit-project.org [2] https://wiki.ubuntu.com/SyncIntegration [3] http://wiki.mandriva.com/en/2008.1_What%27s_New [4] http://www.novell.com/brainshare/general-sessions-2008.html [5] http://libsyncml.opensync.org/ [6] http://cihar.com/gammu/python/ [7] http://code.google.com/p/gdata-python-client/ [8] http://bleu.west.spy.net/~dustin/projects/backpack/ [9] http://code.google.com/p/pyfacebook/ [10] http://www.gtkpod.org/libgpod.html From hadess@hadess.net Mon Mar 31 11:02:50 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A32E375018F; Mon, 31 Mar 2008 11:02:50 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=2 tests=[AWL=0.023, BAYES_00=-2.599, TW_EV=0.077] X-Amavis-OS-Fingerprint: Linux 2.6, seldom 2.4 (older, 4) (up: 2099 hrs), (distance 17, link: ethernet/modem), [195.10.223.155] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzNlZ+OrCgBf; Mon, 31 Mar 2008 11:02:44 +0000 (GMT) Received: from bungle.evilgeniuses.org.uk (bungle.evilgeniuses.org.uk [195.10.223.155]) by menubar.gnome.org (Postfix) with ESMTP id D894A75008B; Mon, 31 Mar 2008 11:02:43 +0000 (GMT) Received: from [192.168.1.7] (cpc4-glfd1-0-0-cust751.glfd.cable.ntl.com [86.16.126.240]) by bungle.evilgeniuses.org.uk (Postfix) with ESMTP id 9E7FF1C0B5CC; Mon, 31 Mar 2008 11:02:41 +0000 (UTC) Subject: Re: Module proposal: Conduit for GNOME 2.24 From: Bastien Nocera To: John Stowers In-Reply-To: <1206959727.5776.1.camel@nzjrs-laptop> References: <1206959727.5776.1.camel@nzjrs-laptop> Content-Type: text/plain; charset=UTF-8 Date: Mon, 31 Mar 2008 12:02:40 +0100 Message-Id: <1206961360.13201.178.camel@cookie.hadess.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Content-Transfer-Encoding: 8bit Cc: conduit-list@gnome.org, desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 11:02:50 -0000 On Mon, 2008-03-31 at 23:35 +1300, John Stowers wrote: > Hey Guys, > > On behalf of the Conduit [1] development team, I would like to propose > Conduit for inclusion in GNOME 2.24 desktop suite. > gnomevfs, > * Our file/folder sync uses gnomevfs That's not very GNOMEy anymore, GIO's the way :) > * [WIP] We have developed an eog plugin for photo upload to a number > of sites, directly from within the application Any chance of working on something similar for Totem and Cheese? http://bugzilla.gnome.org/show_bug.cgi?id=459505 http://bugzilla.gnome.org/show_bug.cgi?id=522210 > * Additional Information: > Our focus for this cycle is the support of mobile devices through both > libsyncml [5] and (python)gammu [6]. This will obviously introduce > additional dependencies on these libraries. And gnome-phone-manager, if I get off my butt. > We are looking forward to, and will be adding support for GIO/GVFS as > soon as it is available to be used from Python. Yay. > We have had firm expressions of interest from Tomboy and Cheese about > using conduit for Sync and Export respectively. Conduits presence in the > desktop set would make their dependency on us for this functionality > more palatable. As mentioned above. I'd like to see the UI reviewed before giving it a +1, as I've had very hard times understanding how to actually make it work. Something a bit more like iSync (at least for the "core" PIM data) would be nice. Cheers From luis.villa@gmail.com Mon Mar 31 12:13:26 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AB6E07501AB for ; Mon, 31 Mar 2008 12:13:26 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=2 tests=[AWL=0.140, BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 6952 hrs), (distance 15, link: (Google 2)), [66.249.82.229] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmlLJSQOAI-u for ; Mon, 31 Mar 2008 12:13:24 +0000 (GMT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by menubar.gnome.org (Postfix) with ESMTP id 20CA175018F for ; Mon, 31 Mar 2008 12:13:23 +0000 (GMT) Received: by wx-out-0506.google.com with SMTP id h26so1422970wxd.9 for ; Mon, 31 Mar 2008 05:13:22 -0700 (PDT) Received: by 10.100.152.15 with SMTP id z15mr15840365and.6.1206965602067; Mon, 31 Mar 2008 05:13:22 -0700 (PDT) Received: by 10.100.6.7 with HTTP; Mon, 31 Mar 2008 05:13:22 -0700 (PDT) Message-ID: <2cb10c440803310513i7f51d902x9fe137a5a7c627fd@mail.gmail.com> Date: Mon, 31 Mar 2008 08:13:22 -0400 From: "Luis Villa" Sender: luis.villa@gmail.com To: "Bastien Nocera" Subject: Re: Module proposal: Conduit for GNOME 2.24 In-Reply-To: <1206961360.13201.178.camel@cookie.hadess.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1206959727.5776.1.camel@nzjrs-laptop> <1206961360.13201.178.camel@cookie.hadess.net> X-Google-Sender-Auth: e17d1b484f9520aa Cc: conduit-list@gnome.org, John Stowers , desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 12:13:27 -0000 On Mon, Mar 31, 2008 at 7:02 AM, Bastien Nocera wrote: > I'd like to see the UI reviewed before giving it a +1, as I've had very > hard times understanding how to actually make it work. Something a bit > more like iSync (at least for the "core" PIM data) would be nice. +1. I tried to use Conduit (the version in F8, whatever that is) and couldn't figure out how to make it do *anything*, much less what I wanted it for (to sync my class readings folder to my Nokia.) Luis From john.stowers.lists@gmail.com Mon Mar 31 20:31:59 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 79EF6750205 for ; Mon, 31 Mar 2008 20:31:59 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11519 hrs), (distance 14, link: (Google 2)), [209.85.198.188] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcwJgXhJk6rI for ; Mon, 31 Mar 2008 20:31:53 +0000 (GMT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by menubar.gnome.org (Postfix) with ESMTP id 54E67750202 for ; Mon, 31 Mar 2008 20:31:52 +0000 (GMT) Received: by rv-out-0910.google.com with SMTP id k20so972936rvb.3 for ; Mon, 31 Mar 2008 13:31:51 -0700 (PDT) Received: by 10.141.15.19 with SMTP id s19mr3758268rvi.39.1206995511642; Mon, 31 Mar 2008 13:31:51 -0700 (PDT) Received: from ?192.168.1.127? ( [118.90.59.226]) by mx.google.com with ESMTPS id k19sm2202919rvb.18.2008.03.31.13.31.47 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Mar 2008 13:31:49 -0700 (PDT) Subject: Re: Module proposal: Conduit for GNOME 2.24 From: John Stowers To: Bastien Nocera In-Reply-To: <1206961360.13201.178.camel@cookie.hadess.net> References: <1206959727.5776.1.camel@nzjrs-laptop> <1206961360.13201.178.camel@cookie.hadess.net> Content-Type: text/plain; charset=utf-8 Date: Tue, 01 Apr 2008 09:33:55 +1300 Message-Id: <1206995635.5835.13.camel@nzjrs-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Content-Transfer-Encoding: 8bit Cc: conduit-list@gnome.org, desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 20:31:59 -0000 > > > * [WIP] We have developed an eog plugin for photo upload to a number > > of sites, directly from within the application > > Any chance of working on something similar for Totem and Cheese? > http://bugzilla.gnome.org/show_bug.cgi?id=459505 > http://bugzilla.gnome.org/show_bug.cgi?id=522210 I am confident that video upload to Youtube and Vimeo will be added this cycle as both services have nice APIs (and bindings). http://bugzilla.gnome.org/show_bug.cgi?id=522120 http://bugzilla.gnome.org/show_bug.cgi?id=524777 > > > * Additional Information: > > Our focus for this cycle is the support of mobile devices through both > > libsyncml [5] and (python)gammu [6]. This will obviously introduce > > additional dependencies on these libraries. > > And gnome-phone-manager, if I get off my butt. Good to hear! I'd like to see the UI reviewed before giving it a +1, as I've had very > hard times understanding how to actually make it work. Something a bit > more like iSync (at least for the "core" PIM data) would be nice. I agree. Such an interface could be easily implemented atop the Conduit DBus interface but I would prefer the consensus of what constitutes 'core' sync come in part from the GNOME community. For example one consequence of getting into GNOME would be that the means for managing Tomboy sync would move from the Conduit GUI into Tomboy [1]. John [1] Well that's what I would like. I hope the Tomboy devs agree! > > Cheers > From john.stowers.lists@gmail.com Mon Mar 31 20:35:41 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98AE2750249 for ; Mon, 31 Mar 2008 20:35:41 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 11521 hrs), (distance 14, link: (Google 2)), [209.85.198.184] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+4zZeXMk-rU for ; Mon, 31 Mar 2008 20:35:35 +0000 (GMT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by menubar.gnome.org (Postfix) with ESMTP id 59BFE750136 for ; Mon, 31 Mar 2008 20:35:30 +0000 (GMT) Received: by rv-out-0910.google.com with SMTP id k20so973663rvb.3 for ; Mon, 31 Mar 2008 13:35:28 -0700 (PDT) Received: by 10.141.203.7 with SMTP id f7mr3774984rvq.7.1206995728865; Mon, 31 Mar 2008 13:35:28 -0700 (PDT) Received: from ?192.168.1.127? ( [118.90.59.226]) by mx.google.com with ESMTPS id f28sm2132235rvb.35.2008.03.31.13.35.25 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Mar 2008 13:35:27 -0700 (PDT) Subject: Re: Module proposal: Conduit for GNOME 2.24 From: John Stowers To: Mathias Hasselmann In-Reply-To: <1206965012.6780.17.camel@localhost> References: <1206959727.5776.1.camel@nzjrs-laptop> <1206961360.13201.178.camel@cookie.hadess.net> <1206965012.6780.17.camel@localhost> Content-Type: text/plain Date: Tue, 01 Apr 2008 09:37:33 +1300 Message-Id: <1206995854.5835.16.camel@nzjrs-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Content-Transfer-Encoding: 7bit Cc: conduit-list@gnome.org, desktop-devel-list@gnome.org, Bastien Nocera X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 20:35:41 -0000 > > ACK. > > Maybe the UI would be more easy to understand if the tree view in the > main window would be replaced by some Glade/GIMP like tool palette. > I am developing a generic tool palette widget for usage > in Glom (and hopefully many other programs) in libegg/toolpalette right > now. [1][2] hehe, yeah I stumbled across this a few weeks ago. I will keep an eye on your progress. > > Also the preferences dialog could use quite some UI love. Its no excuse really, but there are a few things in there (like the MappingDB tab) that are only visible in development releases. > > But I agree that some application like Conduit would greatly benefit > GNOME. > > Ciao, > Mathias > > [1] http://svn.gnome.org/viewvc/libegg/trunk/libegg/toolpalette/ > [2] > http://taschenorakel.de/pictures/screenshots/2008/03/31/testtoolpalette.png > From john.stowers.lists@gmail.com Mon Mar 31 20:44:31 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7610175008A for ; Mon, 31 Mar 2008 20:44:31 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_EV=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 6688 hrs), (distance 16, link: (Google 2)), [64.233.184.232] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDaCDQJIf5tE for ; Mon, 31 Mar 2008 20:44:27 +0000 (GMT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by menubar.gnome.org (Postfix) with ESMTP id 41EF97501C3 for ; Mon, 31 Mar 2008 20:44:26 +0000 (GMT) Received: by wr-out-0506.google.com with SMTP id c55so991199wra.0 for ; Mon, 31 Mar 2008 13:44:25 -0700 (PDT) Received: by 10.141.34.12 with SMTP id m12mr3776654rvj.26.1206996264913; Mon, 31 Mar 2008 13:44:24 -0700 (PDT) Received: from ?192.168.1.127? ( [118.90.59.226]) by mx.google.com with ESMTPS id k41sm2461228rvb.24.2008.03.31.13.44.20 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Mar 2008 13:44:23 -0700 (PDT) Subject: Re: Module proposal: Conduit for GNOME 2.24 From: John Stowers To: Eitan Isaacson In-Reply-To: <1206990207.442.6.camel@macmini> References: <1206959727.5776.1.camel@nzjrs-laptop> <1206990207.442.6.camel@macmini> Content-Type: text/plain; charset=utf-8 Date: Tue, 01 Apr 2008 09:46:28 +1300 Message-Id: <1206996388.5835.28.camel@nzjrs-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Content-Transfer-Encoding: 8bit Cc: conduit-list@gnome.org, desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 20:44:31 -0000 On Mon, 2008-03-31 at 12:03 -0700, Eitan Isaacson wrote: > Hi. > > Conduit in it's current state is not accessible. Is there a way to > create and modify groups and items without using the mouse? This of > course is a very basic access issue. > > Not less important, the canvas in which all the groups and items are > reviewed and edited is inaccessible to assistive technologies. For this > to be accessible, there needs to be keyboard navigation, and proper ATK > interfaces implemented. I am not sure how possible this is to do > directly in python[1]. > > I would give this a +1 if the devs think they could make Conduit > accessible by 2.24. I will have to look into (py)goocanvas to see how/if it supports ATK, and what I will need to do to hook into this. Does anyone have some experience with this sort of thing? In an ideal world, I expected the Gtk+ team to have decided on a new Canvas by now, so I could switch to using that. John > > Cheers, > Eitan. > > > On Mon, 2008-03-31 at 23:35 +1300, John Stowers wrote: > > Hey Guys, > > > > On behalf of the Conduit [1] development team, I would like to propose > > Conduit for inclusion in GNOME 2.24 desktop suite. > > > > * Purpose: Conduit is a synchronization architecture for the GNOME > > desktop. It provides an intuitive GUI for synchronizing things and a > > DBus interface for external applications to do the same. > > > > * Justification: > > Our immediate benefits to the GNOME desktop are very well supported > > multi-site photo/upload and sync (from Fspot, eog and folder), tomboy > > synchronization to a number of places, file/folder sync (including > > intuitive removable volume support, and the ability to do all these > > things peer to peer. We also support many more than these listed, > > however at the cost of additional dependencies. See below for > > clarification. > > > > In implementing these diverse backends, I am confident our abstractions > > are sound, and we will be able to grow with the GNOME desktop and > > support synchronization with any device you can imagine. Applications > > using our DBus interface will get these benefits at no extra cost. > > > > * Dependencies: > > pygtk, > > gnomevfs, > > gnome-python-desktop > 2.22, > > python-gtkmozembed, > > [NEW] pygoocanvas > 0.9.0, > > [NEW] goocanvas > 0.9.0, > >  [NEW] Python 2.5 (for network sync support) > > > > * Resource usage: > > GNOME FTP, GNOME SVN, GNOME bugzilla, translations > > > > * Adoption: > > Packaged for all major distros, expressions of interest for more > > extensive use by Ubuntu [2], Mandriva [3] and Suse [4] > > > > * Gnome-ness: > > * We support Tomboy note sync and Fspot photo sync. In both cases we > > were instrumental in the development of DBus interfaces in the > > respective applications > > * We support evolution-data-server through the new python evolution > > bindings we contributed to GNOME last cycle. > > * Our file/folder sync uses gnomevfs > > * [WIP] We have developed an eog plugin for photo upload to a number > > of sites, directly from within the application > > * [WIP] We have developed a nautilus plugin to enable easy > > file/folder sync > > > > * Additional Information: > > Our focus for this cycle is the support of mobile devices through both > > libsyncml [5] and (python)gammu [6]. This will obviously introduce > > additional dependencies on these libraries. > > > > We are looking forward to, and will be adding support for GIO/GVFS as > > soon as it is available to be used from Python. > > > > We also support the following services although support for them comes > > at the cost of additional dependencies > > * Google contacts, [WIP] calendar, [WIP] documents (requires > > python-gdata [7]) > > * Backpackit.com (require python backpack [8]) > > * Facebook photos (requires pyfacebook [9]) > > * iPod photos (requires libgpod [10]) > > > > Conduit is translated into a number of languages, and features user help > > documentation. However both of these are WIP. > > > > We have had firm expressions of interest from Tomboy and Cheese about > > using conduit for Sync and Export respectively. Conduits presence in the > > desktop set would make their dependency on us for this functionality > > more palatable. > > > > Looking forward to hearing your thoughts > > > > John Stowers > > > > [1] http://www.conduit-project.org > > [2] https://wiki.ubuntu.com/SyncIntegration > > [3] http://wiki.mandriva.com/en/2008.1_What%27s_New > > [4] http://www.novell.com/brainshare/general-sessions-2008.html > > [5] http://libsyncml.opensync.org/ > > [6] http://cihar.com/gammu/python/ > > [7] http://code.google.com/p/gdata-python-client/ > > [8] http://bleu.west.spy.net/~dustin/projects/backpack/ > > [9] http://code.google.com/p/pyfacebook/ > > [10] http://www.gtkpod.org/libgpod.html > > > > > > > > > > _______________________________________________ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > From john.stowers.lists@gmail.com Mon Mar 31 20:48:55 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B83C6750210 for ; Mon, 31 Mar 2008 20:48:55 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_EV=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 6690 hrs), (distance 16, link: (Google 2)), [64.233.184.228] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIKmei7S1uwC for ; Mon, 31 Mar 2008 20:48:51 +0000 (GMT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by menubar.gnome.org (Postfix) with ESMTP id 2386E75021D for ; Mon, 31 Mar 2008 20:48:50 +0000 (GMT) Received: by wr-out-0506.google.com with SMTP id c55so993215wra.0 for ; Mon, 31 Mar 2008 13:48:49 -0700 (PDT) Received: by 10.141.164.13 with SMTP id r13mr3774999rvo.65.1206996528717; Mon, 31 Mar 2008 13:48:48 -0700 (PDT) Received: from ?192.168.1.127? ( [118.90.59.226]) by mx.google.com with ESMTPS id f42sm11695130rvb.13.2008.03.31.13.48.44 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Mar 2008 13:48:46 -0700 (PDT) Subject: Re: Module proposal: Conduit for GNOME 2.24 From: John Stowers To: Adam Schreiber In-Reply-To: <8298be230803311216i577c5db2jf617dbcf68665211@mail.gmail.com> References: <1206959727.5776.1.camel@nzjrs-laptop> <8298be230803311216i577c5db2jf617dbcf68665211@mail.gmail.com> Content-Type: text/plain Date: Tue, 01 Apr 2008 09:50:53 +1300 Message-Id: <1206996653.5835.33.camel@nzjrs-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Content-Transfer-Encoding: 7bit Cc: conduit-list@gnome.org, desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 20:48:56 -0000 On Mon, 2008-03-31 at 15:16 -0400, Adam Schreiber wrote: > I rather like the idea of conduit. I just set up some google calendar > <-> evolution calendar syncs and it worked great. > > Since it's taking passwords and storing them, is it using a secure > method like gnome-keyring? It was, but I had to take it out due to a crasher in the python gnomevfs bindings. That has now been fixed, so I will be able to add this back in this cycle. > Also, to sync a second calendar on the > same account it required me to add the authentication information > again. The concept of persistent accounts probably needs to be > introduced at some point to allow saying sync these 5 google calendars > from the same acount with these matching evo ones without 5 separate > conduit groups. > > Note: There's a proposed SoC project that wants to create persistent > accounts in the About Me capplet. This was discussed briefly with the mugshot folks. The concept of a centralised 'this is my account details on these services' type thing. No resolution was ever really reached, so I would be happy if the SOC project (for example) came and solved these problems for me! John From mathias.hasselmann@gmx.de Mon Mar 31 12:03:47 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 01D1575018F for ; Mon, 31 Mar 2008 12:03:47 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] X-Amavis-OS-Fingerprint: Linux 2.6, seldom 2.4 (older, 4) (up: 3526 hrs), (distance 21, link: ethernet/modem), [213.165.64.20] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU1+LbQD7ztZ for ; Mon, 31 Mar 2008 12:03:39 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 1897F75017C for ; Mon, 31 Mar 2008 12:03:38 +0000 (GMT) Received: (qmail invoked by alias); 31 Mar 2008 12:03:36 -0000 Received: from ip-80-226-0-1.vodafone-net.de (EHLO dali.local) [80.226.0.1] by mail.gmx.net (mp004) with SMTP; 31 Mar 2008 14:03:36 +0200 X-Authenticated: #427294 X-Provags-ID: V01U2FsdGVkX18HPrdm1wcHctWU4yv8LIPNxBj7hDIL13ljtP3ud5 Xj6ljojq2j20qV Received: from [192.168.100.34] (unknown [192.168.100.34]) by dali.local (Postfix) with ESMTP id 48EF917F5A1; Mon, 31 Mar 2008 14:03:14 +0200 (CEST) Subject: Re: Module proposal: Conduit for GNOME 2.24 From: Mathias Hasselmann To: Bastien Nocera In-Reply-To: <1206961360.13201.178.camel@cookie.hadess.net> References: <1206959727.5776.1.camel@nzjrs-laptop> <1206961360.13201.178.camel@cookie.hadess.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ywd/r2qWY6b6Bin5mucs" Organization: http://taschenorakel.de/mathias/about/ Date: Mon, 31 Mar 2008 14:03:32 +0200 Message-Id: <1206965012.6780.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Mon, 31 Mar 2008 20:50:52 +0000 Cc: conduit-list@gnome.org, John Stowers , desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 12:03:47 -0000 --=-ywd/r2qWY6b6Bin5mucs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Montag, den 31.03.2008, 12:02 +0100 schrieb Bastien Nocera: > I'd like to see the UI reviewed before giving it a +1, as I've had > very > hard times understanding how to actually make it work. Something a bit > more like iSync (at least for the "core" PIM data) would be nice. ACK. Maybe the UI would be more easy to understand if the tree view in the main window would be replaced by some Glade/GIMP like tool palette. I am developing a generic tool palette widget for usage in Glom (and hopefully many other programs) in libegg/toolpalette right now. [1][2] Also the preferences dialog could use quite some UI love. But I agree that some application like Conduit would greatly benefit GNOME. Ciao, Mathias [1] http://svn.gnome.org/viewvc/libegg/trunk/libegg/toolpalette/ [2] http://taschenorakel.de/pictures/screenshots/2008/03/31/testtoolpalette.png --=20 Mathias Hasselmann Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ --=-ywd/r2qWY6b6Bin5mucs Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBH8NMU73AS0G6kpDQRArZyAJ0U0hIIzIXrJvn5QM6Lwi7Dyl07gQCcCjG2 KfBjGEEP7gyrQUN12BP3148= =r3Hr -----END PGP SIGNATURE----- --=-ywd/r2qWY6b6Bin5mucs-- From pacho@condmat1.ciencias.uniovi.es Mon Mar 31 19:01:11 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 22852750136 for ; Mon, 31 Mar 2008 19:01:11 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=2 tests=[BAYES_40=-0.185, FORGED_RCVD_HELO=0.135] X-Amavis-OS-Fingerprint: Linux 2.4-2.6 (NAT!) (up: 5321 hrs), (distance 21, link: GPRS, T1, FreeS/WAN), [217.130.24.205] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCnihymK8aJy for ; Mon, 31 Mar 2008 19:01:01 +0000 (GMT) Received: from lnldap1.comunired.com (unknown [217.130.24.205]) by menubar.gnome.org (Postfix) with ESMTP id 30B3175026A for ; Mon, 31 Mar 2008 19:01:00 +0000 (GMT) Received: (qmail 2144 invoked by uid 7007); 31 Mar 2008 19:00:55 -0000 Received: from unknown (HELO [192.168.1.201]) (IX1V7746758@iservicesmail.com@[89.7.232.84]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 31 Mar 2008 19:00:55 -0000 Subject: Re: Module proposal: Conduit for GNOME 2.24 From: Pacho Ramos To: John Stowers In-Reply-To: <1206959727.5776.1.camel@nzjrs-laptop> References: <1206959727.5776.1.camel@nzjrs-laptop> Content-Type: text/plain Organization: pacho@condmat1.ciencias.uniovi.es Date: Mon, 31 Mar 2008 21:00:57 +0200 Message-Id: <1206990057.3533.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Mar 2008 20:50:52 +0000 Cc: conduit-list@gnome.org, desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: pacho@condmat1.ciencias.uniovi.es List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 19:01:11 -0000 Like other people commented there are still a few issues, but would be a great improvement get this in gnome as it's very useful when having access to more than one computer. Thanks a lot for your great work :-) From eitan@ascender.com Mon Mar 31 19:03:54 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 34E86750266 for ; Mon, 31 Mar 2008 19:03:54 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_EV=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 7594 hrs), (distance 15, link: (Google 2)), [64.233.170.186] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjYUwzbiX2GV for ; Mon, 31 Mar 2008 19:03:38 +0000 (GMT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by menubar.gnome.org (Postfix) with ESMTP id 9ABF175024E for ; Mon, 31 Mar 2008 19:03:35 +0000 (GMT) Received: by rn-out-0910.google.com with SMTP id s46so755617rnb.3 for ; Mon, 31 Mar 2008 12:03:33 -0700 (PDT) Received: by 10.142.49.4 with SMTP id w4mr4188203wfw.57.1206990213120; Mon, 31 Mar 2008 12:03:33 -0700 (PDT) Received: from ?10.0.0.13? ( [76.121.53.41]) by mx.google.com with ESMTPS id 30sm2877949wff.11.2008.03.31.12.03.30 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Mar 2008 12:03:31 -0700 (PDT) Subject: Re: Module proposal: Conduit for GNOME 2.24 From: Eitan Isaacson To: John Stowers In-Reply-To: <1206959727.5776.1.camel@nzjrs-laptop> References: <1206959727.5776.1.camel@nzjrs-laptop> Content-Type: text/plain; charset=utf-8 Date: Mon, 31 Mar 2008 12:03:27 -0700 Message-Id: <1206990207.442.6.camel@macmini> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 31 Mar 2008 20:50:52 +0000 Cc: conduit-list@gnome.org, desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 19:03:54 -0000 Hi. Conduit in it's current state is not accessible. Is there a way to create and modify groups and items without using the mouse? This of course is a very basic access issue. Not less important, the canvas in which all the groups and items are reviewed and edited is inaccessible to assistive technologies. For this to be accessible, there needs to be keyboard navigation, and proper ATK interfaces implemented. I am not sure how possible this is to do directly in python[1]. I would give this a +1 if the devs think they could make Conduit accessible by 2.24. Cheers, Eitan. On Mon, 2008-03-31 at 23:35 +1300, John Stowers wrote: > Hey Guys, > > On behalf of the Conduit [1] development team, I would like to propose > Conduit for inclusion in GNOME 2.24 desktop suite. > > * Purpose: Conduit is a synchronization architecture for the GNOME > desktop. It provides an intuitive GUI for synchronizing things and a > DBus interface for external applications to do the same. > > * Justification: > Our immediate benefits to the GNOME desktop are very well supported > multi-site photo/upload and sync (from Fspot, eog and folder), tomboy > synchronization to a number of places, file/folder sync (including > intuitive removable volume support, and the ability to do all these > things peer to peer. We also support many more than these listed, > however at the cost of additional dependencies. See below for > clarification. > > In implementing these diverse backends, I am confident our abstractions > are sound, and we will be able to grow with the GNOME desktop and > support synchronization with any device you can imagine. Applications > using our DBus interface will get these benefits at no extra cost. > > * Dependencies: > pygtk, > gnomevfs, > gnome-python-desktop > 2.22, > python-gtkmozembed, > [NEW] pygoocanvas > 0.9.0, > [NEW] goocanvas > 0.9.0, >  [NEW] Python 2.5 (for network sync support) > > * Resource usage: > GNOME FTP, GNOME SVN, GNOME bugzilla, translations > > * Adoption: > Packaged for all major distros, expressions of interest for more > extensive use by Ubuntu [2], Mandriva [3] and Suse [4] > > * Gnome-ness: > * We support Tomboy note sync and Fspot photo sync. In both cases we > were instrumental in the development of DBus interfaces in the > respective applications > * We support evolution-data-server through the new python evolution > bindings we contributed to GNOME last cycle. > * Our file/folder sync uses gnomevfs > * [WIP] We have developed an eog plugin for photo upload to a number > of sites, directly from within the application > * [WIP] We have developed a nautilus plugin to enable easy > file/folder sync > > * Additional Information: > Our focus for this cycle is the support of mobile devices through both > libsyncml [5] and (python)gammu [6]. This will obviously introduce > additional dependencies on these libraries. > > We are looking forward to, and will be adding support for GIO/GVFS as > soon as it is available to be used from Python. > > We also support the following services although support for them comes > at the cost of additional dependencies > * Google contacts, [WIP] calendar, [WIP] documents (requires > python-gdata [7]) > * Backpackit.com (require python backpack [8]) > * Facebook photos (requires pyfacebook [9]) > * iPod photos (requires libgpod [10]) > > Conduit is translated into a number of languages, and features user help > documentation. However both of these are WIP. > > We have had firm expressions of interest from Tomboy and Cheese about > using conduit for Sync and Export respectively. Conduits presence in the > desktop set would make their dependency on us for this functionality > more palatable. > > Looking forward to hearing your thoughts > > John Stowers > > [1] http://www.conduit-project.org > [2] https://wiki.ubuntu.com/SyncIntegration > [3] http://wiki.mandriva.com/en/2008.1_What%27s_New > [4] http://www.novell.com/brainshare/general-sessions-2008.html > [5] http://libsyncml.opensync.org/ > [6] http://cihar.com/gammu/python/ > [7] http://code.google.com/p/gdata-python-client/ > [8] http://bleu.west.spy.net/~dustin/projects/backpack/ > [9] http://code.google.com/p/pyfacebook/ > [10] http://www.gtkpod.org/libgpod.html > > > > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list From adam.schreiber@gmail.com Mon Mar 31 19:16:43 2008 Return-Path: X-Original-To: conduit-list@gnome.org Delivered-To: conduit-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7AEEE750199 for ; Mon, 31 Mar 2008 19:16:43 +0000 (GMT) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, MIME_BASE64_NO_NAME=0.224, TW_EV=0.077] X-Amavis-OS-Fingerprint: Linux 2.6 (newer, 2) (firewall!) (up: 3841 hrs), (distance 14, link: (Google 2)), [209.85.200.170] Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFyF5nP3ytL9 for ; Mon, 31 Mar 2008 19:16:38 +0000 (GMT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by menubar.gnome.org (Postfix) with ESMTP id CC1567501C3 for ; Mon, 31 Mar 2008 19:16:37 +0000 (GMT) Received: by wf-out-1314.google.com with SMTP id 28so1675591wfa.9 for ; Mon, 31 Mar 2008 12:16:36 -0700 (PDT) Received: by 10.142.241.10 with SMTP id o10mr4164789wfh.165.1206990996038; Mon, 31 Mar 2008 12:16:36 -0700 (PDT) Received: by 10.142.77.10 with HTTP; Mon, 31 Mar 2008 12:16:35 -0700 (PDT) Message-ID: <8298be230803311216i577c5db2jf617dbcf68665211@mail.gmail.com> Date: Mon, 31 Mar 2008 15:16:35 -0400 From: "Adam Schreiber" Sender: adam.schreiber@gmail.com To: "John Stowers" Subject: Re: Module proposal: Conduit for GNOME 2.24 In-Reply-To: <1206959727.5776.1.camel@nzjrs-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <1206959727.5776.1.camel@nzjrs-laptop> X-Google-Sender-Auth: 01a69218e628ff48 X-Mailman-Approved-At: Mon, 31 Mar 2008 20:50:52 +0000 Cc: conduit-list@gnome.org, desktop-devel-list@gnome.org X-BeenThere: conduit-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 19:16:43 -0000 SSByYXRoZXIgbGlrZSB0aGUgaWRlYSBvZiBjb25kdWl0LiAgSSBqdXN0IHNldCB1cCBzb21lIGdv b2dsZSBjYWxlbmRhcgo8LT4gZXZvbHV0aW9uIGNhbGVuZGFyIHN5bmNzIGFuZCBpdCB3b3JrZWQg Z3JlYXQuCgpTaW5jZSBpdCdzIHRha2luZyBwYXNzd29yZHMgYW5kIHN0b3JpbmcgdGhlbSwgaXMg aXQgdXNpbmcgYSBzZWN1cmUKbWV0aG9kIGxpa2UgZ25vbWUta2V5cmluZz8gIEFsc28sIHRvIHN5 bmMgYSBzZWNvbmQgY2FsZW5kYXIgb24gdGhlCnNhbWUgYWNjb3VudCBpdCByZXF1aXJlZCBtZSB0 byBhZGQgdGhlIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uCmFnYWluLiAgVGhlIGNvbmNlcHQg b2YgcGVyc2lzdGVudCBhY2NvdW50cyBwcm9iYWJseSBuZWVkcyB0byBiZQppbnRyb2R1Y2VkIGF0 IHNvbWUgcG9pbnQgdG8gYWxsb3cgc2F5aW5nIHN5bmMgdGhlc2UgNSBnb29nbGUgY2FsZW5kYXJz CmZyb20gdGhlIHNhbWUgYWNvdW50IHdpdGggdGhlc2UgbWF0Y2hpbmcgZXZvIG9uZXMgd2l0aG91 dCA1IHNlcGFyYXRlCmNvbmR1aXQgZ3JvdXBzLgoKTm90ZTogVGhlcmUncyBhIHByb3Bvc2VkIFNv QyBwcm9qZWN0IHRoYXQgd2FudHMgdG8gY3JlYXRlIHBlcnNpc3RlbnQKYWNjb3VudHMgaW4gdGhl IEFib3V0IE1lIGNhcHBsZXQuCgpDaGVlcnMsCgpBZGFtCgpPbiBNb24sIE1hciAzMSwgMjAwOCBh dCA2OjM1IEFNLCBKb2huIFN0b3dlcnMKPGpvaG4uc3Rvd2Vycy5saXN0c0BnbWFpbC5jb20+IHdy b3RlOgo+IEhleSBHdXlzLAo+Cj4gIE9uIGJlaGFsZiBvZiB0aGUgQ29uZHVpdCDvu79bMV0gZGV2 ZWxvcG1lbnQgdGVhbSwgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UKPiAgQ29uZHVpdCBmb3IgaW5j bHVzaW9uIGluIEdOT01FIDIuMjQgZGVza3RvcCBzdWl0ZS4KPgo+ICAqIFB1cnBvc2U6IENvbmR1 aXQgaXMgYSBzeW5jaHJvbml6YXRpb24gYXJjaGl0ZWN0dXJlIGZvciB0aGUgR05PTUUKPiAgZGVz a3RvcC4gSXQgcHJvdmlkZXMgYW4gaW50dWl0aXZlIEdVSSBmb3Igc3luY2hyb25pemluZyB0aGlu Z3MgYW5kIGEKPiAgREJ1cyBpbnRlcmZhY2UgZm9yIGV4dGVybmFsIGFwcGxpY2F0aW9ucyB0byBk byB0aGUgc2FtZS4KPgo+ICAqIEp1c3RpZmljYXRpb246Cj4gIE91ciBpbW1lZGlhdGUgYmVuZWZp dHMgdG8gdGhlIEdOT01FIGRlc2t0b3AgYXJlIHZlcnkgd2VsbCBzdXBwb3J0ZWQKPiAgbXVsdGkt c2l0ZSBwaG90by91cGxvYWQgYW5kIHN5bmMgKGZyb20gRnNwb3QsIGVvZyBhbmQgZm9sZGVyKSwg dG9tYm95Cj4gIHN5bmNocm9uaXphdGlvbiB0byBhIG51bWJlciBvZiBwbGFjZXMsIGZpbGUvZm9s ZGVyIHN5bmMgKGluY2x1ZGluZwo+ICBpbnR1aXRpdmUgcmVtb3ZhYmxlIHZvbHVtZSBzdXBwb3J0 LCBhbmQgdGhlIGFiaWxpdHkgdG8gZG8gYWxsIHRoZXNlCj4gIHRoaW5ncyBwZWVyIHRvIHBlZXIu IFdlIGFsc28gc3VwcG9ydCBtYW55IG1vcmUgdGhhbiB0aGVzZSBsaXN0ZWQsCj4gIGhvd2V2ZXIg YXQgdGhlIGNvc3Qgb2YgYWRkaXRpb25hbCBkZXBlbmRlbmNpZXMuIFNlZSBiZWxvdyBmb3IKPiAg Y2xhcmlmaWNhdGlvbi4KPgo+ICBJbiBpbXBsZW1lbnRpbmcgdGhlc2UgZGl2ZXJzZSBiYWNrZW5k cywgSSBhbSBjb25maWRlbnQgb3VyIGFic3RyYWN0aW9ucwo+ICBhcmUgc291bmQsIGFuZCB3ZSB3 aWxsIGJlIGFibGUgdG8gZ3JvdyB3aXRoIHRoZSBHTk9NRSBkZXNrdG9wIGFuZAo+ICBzdXBwb3J0 IHN5bmNocm9uaXphdGlvbiB3aXRoIGFueSBkZXZpY2UgeW91IGNhbiBpbWFnaW5lLiBBcHBsaWNh dGlvbnMKPiAgdXNpbmcgb3VyIERCdXMgaW50ZXJmYWNlIHdpbGwgZ2V0IHRoZXNlIGJlbmVmaXRz IGF0IG5vIGV4dHJhIGNvc3QuCj4KPiAgKiBEZXBlbmRlbmNpZXM6Cj4gICBweWd0aywKPiAgIGdu b21ldmZzLAo+ICAgZ25vbWUtcHl0aG9uLWRlc2t0b3AgPiAyLjIyLAo+ICAgcHl0aG9uLWd0a21v emVtYmVkLAo+ICAgW05FV10gcHlnb29jYW52YXMgPiAwLjkuMCwKPiAgIO+7v1tORVddIGdvb2Nh bnZhcyA+IDAuOS4wLAo+ICDvu78gIO+7v1tORVddIFB5dGhvbiAyLjUgKGZvciBuZXR3b3JrIHN5 bmMgc3VwcG9ydCkKPgo+ICAqIFJlc291cmNlIHVzYWdlOgo+ICAgR05PTUUgRlRQLCBHTk9NRSBT Vk4sIEdOT01FIGJ1Z3ppbGxhLCB0cmFuc2xhdGlvbnMKPgo+ICAqIEFkb3B0aW9uOgo+ICAgUGFj a2FnZWQgZm9yIGFsbCBtYWpvciBkaXN0cm9zLCBleHByZXNzaW9ucyBvZiBpbnRlcmVzdCBmb3Ig bW9yZQo+ICBleHRlbnNpdmUgdXNlIGJ5IFVidW50dSDvu79bMl0sIE1hbmRyaXZhIO+7v1szXSBh bmQgU3VzZSDvu79bNF0KPgo+ICAqIEdub21lLW5lc3M6Cj4gICAqIFdlIHN1cHBvcnQgVG9tYm95 IG5vdGUgc3luYyBhbmQgRnNwb3QgcGhvdG8gc3luYy4gSW4gYm90aCBjYXNlcyB3ZQo+ICB3ZXJl IGluc3RydW1lbnRhbCBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgREJ1cyBpbnRlcmZhY2VzIGluIHRo ZQo+ICByZXNwZWN0aXZlIGFwcGxpY2F0aW9ucwo+ICAgKiBXZSBzdXBwb3J0IGV2b2x1dGlvbi1k YXRhLXNlcnZlciB0aHJvdWdoIHRoZSBuZXcgcHl0aG9uIGV2b2x1dGlvbgo+ICBiaW5kaW5ncyB3 ZSBjb250cmlidXRlZCB0byBHTk9NRSBsYXN0IGN5Y2xlLgo+ICAgKiBPdXIgZmlsZS9mb2xkZXIg c3luYyB1c2VzIGdub21ldmZzCj4gICAqIO+7v1tXSVBdIFdlIGhhdmUgZGV2ZWxvcGVkIGFuIGVv ZyBwbHVnaW4gZm9yIHBob3RvIHVwbG9hZCB0byBhIG51bWJlcgo+ICBvZiBzaXRlcywgZGlyZWN0 bHkgZnJvbSB3aXRoaW4gdGhlIGFwcGxpY2F0aW9uCj4gICAqIO+7v++7v1tXSVBdIFdlIGhhdmUg ZGV2ZWxvcGVkIGEgbmF1dGlsdXMgcGx1Z2luIHRvIGVuYWJsZSBlYXN5Cj4gIGZpbGUvZm9sZGVy IHN5bmMKPgo+ICAqIEFkZGl0aW9uYWwgSW5mb3JtYXRpb246Cj4gIE91ciBmb2N1cyBmb3IgdGhp cyBjeWNsZSBpcyB0aGUgc3VwcG9ydCBvZiBtb2JpbGUgZGV2aWNlcyB0aHJvdWdoIGJvdGgKPiAg bGlic3luY21sIO+7v++7v1s1XSBhbmQgKHB5dGhvbilnYW1tdSDvu7/vu79bNl0uIFRoaXMgd2ls bCBvYnZpb3VzbHkgaW50cm9kdWNlCj4gIGFkZGl0aW9uYWwgZGVwZW5kZW5jaWVzIG9uIHRoZXNl IGxpYnJhcmllcy4KPgo+ICBXZSBhcmUgbG9va2luZyBmb3J3YXJkIHRvLCBhbmQgd2lsbCBiZSBh ZGRpbmcgc3VwcG9ydCBmb3IgR0lPL0dWRlMgYXMKPiAgc29vbiBhcyBpdCBpcyBhdmFpbGFibGUg dG8gYmUgdXNlZCBmcm9tIFB5dGhvbi4KPgo+ICBXZSBhbHNvIHN1cHBvcnQgdGhlIGZvbGxvd2lu ZyBzZXJ2aWNlcyBhbHRob3VnaCBzdXBwb3J0IGZvciB0aGVtIGNvbWVzCj4gIGF0IHRoZSBjb3N0 IG9mIGFkZGl0aW9uYWwgZGVwZW5kZW5jaWVzCj4gICAqIEdvb2dsZSBjb250YWN0cywg77u/W1dJ UF0gY2FsZW5kYXIsIO+7v1tXSVBdIGRvY3VtZW50cyAocmVxdWlyZXMKPiAgcHl0aG9uLWdkYXRh IO+7v1s3XSkKPiAgICogQmFja3BhY2tpdC5jb20gKHJlcXVpcmUgcHl0aG9uIGJhY2twYWNrIO+7 v1s4XSkKPiAgICogRmFjZWJvb2sgcGhvdG9zIChyZXF1aXJlcyBweWZhY2Vib29rIO+7v1s5XSkK PiAgICogaVBvZCBwaG90b3MgKHJlcXVpcmVzIGxpYmdwb2Qg77u/77u/WzEwXSkKPgo+ICBDb25k dWl0IGlzIHRyYW5zbGF0ZWQgaW50byBhIG51bWJlciBvZiBsYW5ndWFnZXMsIGFuZCBmZWF0dXJl cyB1c2VyIGhlbHAKPiAgZG9jdW1lbnRhdGlvbi4gSG93ZXZlciBib3RoIG9mIHRoZXNlIGFyZSBX SVAuCj4KPiAgV2UgaGF2ZSBoYWQgZmlybSBleHByZXNzaW9ucyBvZiBpbnRlcmVzdCBmcm9tIFRv bWJveSBhbmQgQ2hlZXNlIGFib3V0Cj4gIHVzaW5nIGNvbmR1aXQgZm9yIFN5bmMgYW5kIEV4cG9y dCByZXNwZWN0aXZlbHkuIENvbmR1aXRzIHByZXNlbmNlIGluIHRoZQo+ICBkZXNrdG9wIHNldCB3 b3VsZCBtYWtlIHRoZWlyIGRlcGVuZGVuY3kgb24gdXMgZm9yIHRoaXMgZnVuY3Rpb25hbGl0eQo+ ICBtb3JlIHBhbGF0YWJsZS4KPgo+ICBMb29raW5nIGZvcndhcmQgdG8gaGVhcmluZyB5b3VyIHRo b3VnaHRzCj4KPiAgSm9obiBTdG93ZXJzCj4KPiAg77u/WzFdIGh0dHA6Ly93d3cuY29uZHVpdC1w cm9qZWN0Lm9yZwo+ICDvu79bMl0gaHR0cHM6Ly93aWtpLnVidW50dS5jb20vU3luY0ludGVncmF0 aW9uCj4gIO+7v1szXSBodHRwOi8vd2lraS5tYW5kcml2YS5jb20vZW4vMjAwOC4xX1doYXQlMjdz X05ldwo+ICDvu79bNF0gaHR0cDovL3d3dy5ub3ZlbGwuY29tL2JyYWluc2hhcmUvZ2VuZXJhbC1z ZXNzaW9ucy0yMDA4Lmh0bWwKPiAg77u/77u/WzVdIGh0dHA6Ly9saWJzeW5jbWwub3BlbnN5bmMu b3JnLwo+ICDvu7/vu79bNl0gaHR0cDovL2NpaGFyLmNvbS9nYW1tdS9weXRob24vCj4gIO+7v1s3 XSBodHRwOi8vY29kZS5nb29nbGUuY29tL3AvZ2RhdGEtcHl0aG9uLWNsaWVudC8KPiAg77u/Wzhd IGh0dHA6Ly9ibGV1Lndlc3Quc3B5Lm5ldC9+ZHVzdGluL3Byb2plY3RzL2JhY2twYWNrLwo+ICDv u79bOV0gaHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL3B5ZmFjZWJvb2svCj4gIO+7v1sxMF0gaHR0 cDovL3d3dy5ndGtwb2Qub3JnL2xpYmdwb2QuaHRtbAo+Cj4KPgo+Cj4gIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gIGRlc2t0b3AtZGV2ZWwtbGlzdCBt YWlsaW5nIGxpc3QKPiAgZGVza3RvcC1kZXZlbC1saXN0QGdub21lLm9yZwo+ICBodHRwOi8vbWFp bC5nbm9tZS5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXNrdG9wLWRldmVsLWxpc3QK