← Back to team overview

tomdroid-dev team mailing list archive

Re: Web sync branch hurdles


On Sun, Nov 15, 2009 at 6:19 AM, Benoit Garret
<benoit.garret_launchpad@xxxxxxxx> wrote:
> Hey,
> On Mon, Nov 9, 2009 at 11:01 PM, Sandy Armstrong
> <sanfordarmstrong@xxxxxxxxx> wrote:
>> On Mon, Nov 9, 2009 at 1:36 PM, Benoit Garret
>> <benoit.garret_launchpad@xxxxxxxx> wrote:
>>> I tested U1 with the patch you provided below (which should be the
>>> only changes required to support oauth 1.0a). You're absolutely
>>> correct in your assumption that Tomdroid is handling the tomdroid://
>>> url, that's why another instance seems to be started (we should only
>>> show the popup on the first run). I get the following exception when
>>> trying to do the last part of the auth process:
>>> OAuthExpectationFailedException: Request token or token secret not set
>>> in server reply. The service provider you use is probably buggy.
>> That is the same exception I got, and tried ignoring, with
>> unsatisfactory results.  :-)  I'd really like to see the response sent
>> by U1 here...copying Signpost source directly in to Tomdroid bzr would
>> allow debugging deeper into Signpost, right?
> I made a few commits today:
> * the expectation failed exception is a known problem in signpost:
> http://code.google.com/p/oauth-signpost/issues/detail?id=20#c8. I
> committed a hack which should fix the issue while we wait for a proper
> fix from upstream.
> * the notes api url was hardcoded, I'm now GETting the proper resource
> from the server.
> Syncing with U1 now works (for me) but more feedback is welcome ;-) .

Awesome!  I just pulled your changes and they are working fine on
Android 1.6.  Some things I noticed:

* I have to manually change the 1.0a pref to true.  But I'm pretty
sure that there's no harm in treating Snowy or other OAuth 1.0 servers
identically to an OAuth 1.0a server, as long as you don't freak out
when oauth_verifier isn't returned (does signpost freak out in that
situation?).  It would suck to have users have to pick OAuth
versions...maybe we should just bite the bullet and add 1.0a support
to django-piston for snowy so that Tomdroid can safely assume 1.0a
(this is assuming signpost really can't handle 1.0a mode on a 1.0

* Should probably rename "Snowy" in the UI to "Tomboy Web" (that's the
string we use in Tomboy, and in general it's how we refer to
"something that implements the Tomboy Web REST API").  After all,
U1/Midgard/etc != Snowy.

* Syncing notes was super slow and I had no idea it was working.  I
assumed it had failed because I was still able to press the "Sync"
button.  This can be broken down into a few problems:
  1. No indication that sync is in progress
  2. Long delay before I even see first note sync'd in the log
  3. Each note takes almost a second to sync
  4. Can still press Sync button (no idea if this means multiple sync
operations are running)
These are all totally fixable, though.

* The Tomdroid UI seems slow in general, but I haven't deployed it to
my G1 yet so I can't really quantify that.  Also, for all I know there
is another sync job going on in the background from pressing the
button too many times. :-P

Anyway, great progress...it was really exciting to see my notes.  What
issues are blocking a new release with these features?


Follow ups