gContactSync 0.4 Plans

[Josh Geenen]

I haven't started version 0.4, but here are my basic plans.

It will NOT support Thunderbird 2.

Supported Applications

• Thunderbird 3.0 beta 3 and above
• Seamonkey 2.0 beta 1 and above

Possible Features

• Improved account settings/wizard
• Preferences for each synchronized address book
• Possible performance improvements
• Interfaces for adding account types (from sources other than Google, such as openCRX or Plaxo).*

Potential Plugins

These are some services that appear to have an API that is potentially compatible with gContactSync 0.4.  I can promise that I won't have time to make all these, so please let me know which ones you would like so I can prioritize.

• openCRX
• Plaxo
• Yahoo!
• Facebook
• MySpace

*Some account types, such as Facebook or MySpace could be implemented, but they would probably require the use of a third-party website which would redirect to a login/confirmation page (from Facebook or MySpace) and then redirects back to the original page with an authentication token.  Also, MySpace only allows very limited information about one's friends (nickname, thumbnail URL, and profile URL).  I haven't looked into Facebook's API yet.

[tanstaafl]

First - I just now found gContactSync, and all I can say is thank you! I have tried many other 'solutions' and none of them were satisfactory... but gContactSync just works...

I haven't started version 0.4, but here are my basic plans.

snip

Possible Features

• Interfaces for adding account types (from sources other than Google)

If this means that I would be able to use, say, my own FTP server, and sync my contacts with a fileformat native to gContactSync, then I can only say... YES!! PLEASE!!!!

This one would be awesome...

[Josh Geenen]

Hello again,

If this means that I would be able to use, say, my own FTP server, and sync my contacts with a fileformat native to gContactSync, then I can only say... YES!! PLEASE!!!!

In theory this would be possible as long as somebody implements the new interface to do that.

[tanstaafl]

Hi Josh,

I was thinking more along the lines of gContactSync just storing the Contacts in some kind of standard format on the FTP server, like say LDIF or something (probably with (a/some) special field(s) for keeping status info - ie, last sync date/time, etc), and then syncing with that.

Similar to how Foxmarks (now XMarks) works for syncing Bookmarks - it uses its own format (.json file). I've been using it with my own FTP server to sync my bookmarks for well over a year, and it is still rock-solid, although I'll probably have to move to using SyncPlaces eventually, if/when Mozilla makes a change that breaks compatability, since I have no desire to move to XMarks...

[Josh Geenen]

Hey,

That makes sense, and is similar to how gContactSync works now.  It basically authenticates and trades a username/password for a token that lasts for a certain period (months) and uses that token to fetch an Atom/XML feed of groups and then contacts.  A plugin could reuse much of the existing code and store the contacts and groups in a (nearly?) identical format on the server.  Google's API has some restrictions on the amount and type of information stored, but a few XML, JSON, or any other format easy to parse in JavaScript, files on a server would not have those restrictions.  That would allow synchronizing every bit of information from a contact between multiple address books on multiple computers for those with access to a server.

I will definitely keep this in mind when working on 0.3 and starting on 0.4

Josh

[tanstaafl]

 

Awesome Josh... hope your exams/quiz/career fair are going well...

[tanstaafl]

Hey Josh,

Have you given any more thought to a 'native' file format for syncing, so we could optionally sync either to a LAN share, or to a personal/private FTP server?

Even though this kind of eliminates the 'g' aspect of gContactSync, I think it would be an incredibly useful and popular option.

Hope you're having a great holiday season, and really looking forward to playing with 0.3 in the next few weeks...

Charles

[Josh Geenen]

Have you given any more thought to a 'native' file format for syncing, so we could optionally sync either to a LAN share, or to a personal/private FTP server?

Even though this kind of eliminates the 'g' aspect of gContactSync, I think it would be an incredibly useful and popular option.

I've been busy with 0.3, so I haven't finished thinking about it yet, but I'll keep it in mind when I get started on 0.4.  I do not anticipate it being any more difficult to implement than any other new account type.

The g can stand for anything, maybe global once it works with multiple account types.

I finished all my finals and my part-time job/internship so I should have a good holiday season with actual free time!

Have a good holiday season, too!

Josh

[tanstaafl]

Have you given any more thought to a 'native' file format for syncing, so we could optionally sync either to a LAN share, or to a personal/private FTP server?

Even though this kind of eliminates the 'g' aspect of gContactSync, I think it would be an incredibly useful and popular option.

I've been busy with 0.3, so I haven't finished thinking about it yet, but I'll keep it in mind when I get started on 0.4.  I do not anticipate it being any more difficult to implement than any other new account type.

Actually, I would think it would be much easier, since you didn't have to worry about an API changing on you. *You* define the file format, and that's the end of it. The local/LAN filesystem support I would think would be fairly easy (said the non-programmer who doesn't know a thing about what is easy and what is hard when it comes to programming) - - at least compared to support for FTP - but for that maybe you could add a requirement to install FireFTP and leverage its very mature FTP support? Or borrow code from it? Anyway, sorry, getting excited and thinking out loud...

The g can stand for anything, maybe global once it works with multiple account types.

Heh, good point...

I finished all my finals and my part-time job/internship so I should have a good holiday season with actual free time!

Have a good holiday season, too!

Josh

Ho-ho-ho!

[Josh Geenen]

Actually, I would think it would be much easier, since you didn't have to worry about an API changing on you. *You* define the file format, and that's the end of it. The local/LAN filesystem support I would think would be fairly easy (said the non-programmer who doesn't know a thing about what is easy and what is hard when it comes to programming) - Wink - at least compared to support for FTP - but for that maybe you could add a requirement to install FireFTP and leverage its very mature FTP support? Or borrow code from it? Anyway, sorry, getting excited and thinking out loud...

On the side of gContactSync a plugin would be fairly straightforward since, like you said, the API would be created with the sole intention of storing and synchronizing contacts with Thunderbird and perhaps other sources.
I was thinking that it would be easiest to use a web server and write a simple API with PHP that stores contacts in a MySQL database.  The requirements would be Apache, MySQL, and some PHP scripts that I and/or someone else write.  Apache and MySQL are both free and open source and already exist on most web servers.

If I do go this route I would host it on pirules.org for testing purposes.

[tanstaafl]

Actually, I would think it would be much easier, since you didn't have to worry about an API changing on you. *You* define the file format, and that's the end of it. The local/LAN filesystem support I would think would be fairly easy (said the non-programmer who doesn't know a thing about what is easy and what is hard when it comes to programming) - Wink - at least compared to support for FTP - but for that maybe you could add a requirement to install FireFTP and leverage its very mature FTP support? Or borrow code from it? Anyway, sorry, getting excited and thinking out loud...

On the side of gContactSync a plugin would be fairly straightforward since, like you said, the API would be created with the sole intention of storing and synchronizing contacts with Thunderbird and perhaps other sources.
I was thinking that it would be easiest to use a web server and write a simple API with PHP that stores contacts in a MySQL database.  The requirements would be Apache, MySQL, and some PHP scripts that I and/or someone else write.  Apache and MySQL are both free and open source and already exist on most web servers.

Interesting idea, and I like it - but I'm not sure how this would be considered 'easier' than simply defining a file format/API (custom ldif?), and syncing to a local (or remote) filesystem. This only requires access to the filesystem, no apps (other than TB and gContactSync) required. This format could then be extended to store the raw data in a database for anyone who wants/needs a more robust solution.

Being able to simply sync to a local filesystem would be awesome for organizations like ours that just want to have locally shared address books (some that can be read-only (controlled by an Admin), and some that are fully 2 way syncable), but not require a web server/database to accomplish it.

Many people - especially tech types - already have the infrastructure setup - for example, I have 3 different remote filesystems under my direct control I would/could sync with, as well as a few accounts (rsync.net, dreamhost, etc) I could use (and I would, for redundancy/backup purposes).

If I do go this route I would host it on pirules.org for testing purposes.

I really look forward to being able to help you flesh out all of the bugs...

Hope your holidays were great!

[Josh Geenen]

Interesting idea, and I like it - but I'm not sure how this would be considered 'easier' than simply defining a file format/API (custom ldif?), and syncing to a local (or remote) filesystem. This only requires access to the filesystem, no apps (other than TB and gContactSync) required. This format could then be extended to store the raw data in a database for anyone who wants/needs a more robust solution.

Being able to simply sync to a local filesystem would be awesome for organizations like ours that just want to have locally shared address books (some that can be read-only (controlled by an Admin), and some that are fully 2 way syncable), but not require a web server/database to accomplish it.

Many people - especially tech types - already have the infrastructure setup - for example, I have 3 different remote filesystems under my direct control I would/could sync with, as well as a few accounts (rsync.net, dreamhost, etc) I could use (and I would, for redundancy/backup purposes).

It looks like the add-on Addressbooks Synchronizer sort of does this, although it just transfers the AB file and doesn't actually synchronize.  I do understand how that option would be useful; I just have more experience with web development than remote filesystem synchronization.

[tanstaafl]

Yeah, I was aware of that one, and it would work for the 'read-only' Address Books - although I haven't tested it yet, so don't even know if it supports multiple ABs or not...

I have an idea... maybe you could take a peek at the code for the old Foxmarks extension (or even the current XMarks)? Thats exactly what it does - it syncs the bookmarks to a local file (they call theirs a .json file whatever that is). Maybe that would be enough for you to figure out how to do it to a local filesystem?

I have an older Foxmarks extension (before they mangled it to support syncing everything) if you'd like to take a look...

I hated the direction XMarks was going so I just changed the version of Foxmarks to 9.9 so it'd never find an update again...