Author Topic: gContactSync 0.4 Plans  (Read 17284 times)

Josh Geenen

  • gContactSync Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 720
  • Karma: +5/-0
    • Pi Rules.org
gContactSync 0.4 Plans
« on: July 03, 2009, 03:57:42 PM »
I haven't started version 0.4, but here are my basic plans.

It will NOT officially support Thunderbird 2 or 3.

Supported Applications
  • Thunderbird 5 and above
  • Seamonkey 2.0 beta 1 and above

Possible Features
  • Improved account settings/wizard
  • Sync more than one account with the same address book
  • Add new contacts to a default mailing list/group)
  • 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.

Some services are read-only, such as those already supported in 0.3 for importing.  Additionally, some of these 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.  Try Import in version 0.3 to see how this is done.

  • openCRX
  • Plaxo
  • Yahoo!
  • Facebook
  • MySpace
  • Twitter
  • LinkedIn
  • Generic (remote?) sqlite database
« Last Edit: July 12, 2011, 08:37:18 PM by Josh Geenen »
gContactSync: info FAQs

tanstaafl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 122
  • Karma: +1/-0
Re: gContactSync 0.4 Plans
« Reply #1 on: July 14, 2009, 02:03:41 PM »
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

  • gContactSync Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 720
  • Karma: +5/-0
    • Pi Rules.org
Re: gContactSync 0.4 Plans
« Reply #2 on: July 14, 2009, 07:46:54 PM »
Hello again,

Quote
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.
gContactSync: info FAQs

tanstaafl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 122
  • Karma: +1/-0
Re: gContactSync 0.4 Plans
« Reply #3 on: September 26, 2009, 04:36:38 PM »
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

  • gContactSync Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 720
  • Karma: +5/-0
    • Pi Rules.org
Re: gContactSync 0.4 Plans
« Reply #4 on: October 01, 2009, 08:45:27 AM »
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
gContactSync: info FAQs

tanstaafl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 122
  • Karma: +1/-0
Re: gContactSync 0.4 Plans
« Reply #5 on: October 01, 2009, 08:55:11 AM »
 ;D

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

tanstaafl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 122
  • Karma: +1/-0
Re: gContactSync 0.4 Plans
« Reply #6 on: December 16, 2009, 02:56:58 PM »
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

  • gContactSync Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 720
  • Karma: +5/-0
    • Pi Rules.org
Re: gContactSync 0.4 Plans
« Reply #7 on: December 16, 2009, 04:19:09 PM »
Quote
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
gContactSync: info FAQs

tanstaafl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 122
  • Karma: +1/-0
Re: gContactSync 0.4 Plans
« Reply #8 on: December 16, 2009, 04:46:55 PM »
Quote
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...

Quote from: Josh Geenen
The g can stand for anything, maybe global once it works with multiple account types.

Heh, good point... :)

Quote from: Josh Geenen
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

  • gContactSync Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 720
  • Karma: +5/-0
    • Pi Rules.org
Re: gContactSync 0.4 Plans
« Reply #9 on: January 01, 2010, 01:13:29 PM »
Quote
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.
gContactSync: info FAQs

tanstaafl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 122
  • Karma: +1/-0
Re: gContactSync 0.4 Plans
« Reply #10 on: January 01, 2010, 01:39:55 PM »
Quote
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).

Quote
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

  • gContactSync Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 720
  • Karma: +5/-0
    • Pi Rules.org
Re: gContactSync 0.4 Plans
« Reply #11 on: January 15, 2010, 09:53:58 AM »
Quote
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.
gContactSync: info FAQs

tanstaafl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 122
  • Karma: +1/-0
Re: gContactSync 0.4 Plans
« Reply #12 on: January 15, 2010, 01:38:49 PM »
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...

irneb

  • Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
Re: gContactSync 0.4 Plans
« Reply #13 on: March 03, 2011, 07:49:25 AM »
Regarding the "web" based contacts ... maybe use something similar to WebMail extension (http://webmail.mozdev.org/). I'm not sure if they also implement contacts already, but at least you can look at their source code to see how they've done the mail connection. Though, I'd imagine that someone who has a free Yahoo! or such would in any case also have WebMail on TB - there's no other way of working with your emails. So perhaps it would be better to incorporate contacts into WebMail for those servers (if it's not already so).

As for a local / ftp synchronizer (as opposed to AB Sync's basic copy entire file as backup - instead of really SYNC), could I suggest that you use a VCF file format? Either one VCF file per contact, or a combined VCF. That would allow for nearly all phone's to be synced to and from TB, as most of them (especially iPhone & Andriod) can read & write VCF files. Even Nokia can work with these through the OVI suite. So effectively doing this would sort out much of the hassles many have with their phones & TB (i.e. having a "standard" answer of use GMail to sync your phone - WTF). The VCF files also work into TB through the MoreFunctionForAddressBook addon, and can be opened in most other contact managers (even Outlook works with them - go figure)!

The MySQL is possibly also a good idea for shared Address Books, but then why would one want to use MySQL (or some other DB like FireBird / Postgre / etc.) instead of LDAP?

BTW, I've been testing this quite extensively. I like to group my contacts a bit (especially since they're running close to 2000 at the moment), but TB and Google's methods of grouping them don't work too well together. Say I add a category to one (or more) contacts then sync, I'm told that the Google server was updated with that amount of contacts - but that doesn't show anything in Google. Neither does the category get returned if I then Reset the folder in TB. So categories aren't used at all, though they're a much closer analogy to Google's "Groups". Would it be possible to have these work instead of using as at present the Mailing List? Probably as an option, since some may not want it that way.

Unfortunately TB's address book is rather pedestrian, it does have these "Categories" - but no way to view them. Except typing the Category into the search field and selecting "Category" from the "What to search" drop-down. So on 2nd thought, your implementation is probably the "nicest", it just doesn't work too well with the rest of TB's stuff (such as anti-spam filtering on specific address books). Of course to get around that one could always add another AB synced to only one of Google's groups - but that means you're getting some duplication - which is a pain when you use the Auto-Lookup when typing into a message's To field(s). Thus I'd like to see this as an option (by default turned off), so those that want it one way, can at least do so.

Yet even if the Category<-->Group idea isn't implemented, I'd at least want to see the Category saved into something like a custom field in the Google Contact. At least then this type of info won't get lost as it is at present with 0.3.2.

tanstaafl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 122
  • Karma: +1/-0
Re: gContactSync 0.4 Plans
« Reply #14 on: March 03, 2011, 08:09:16 AM »
I do understand how that option (syncing to local filesystem) would be useful; I just have more experience with web development than remote filesystem synchronization.

Another point - you said 'remote filesystem', and what I'm really talking about is a *local* file *format*, and again, one completely under your control...

After properly defining the local format so it is rock solid, you could then just extend that to syncing with some web based service (WebDAV? Other?) that could use whatever it wanted on the backend (database, or just syncing the file to the remote filesystem... I'm probably not making much sense as far as the technical aspects are concerned, but hopefully the concept is making some sense...

The part about *remote* filesystems would/could come later (possibly), ie, it would be nice to be able to synce using a secure FTP server (maybe take the FireFTP extension for Firefox and borrow some code (if their license allows for it) as a shortcut...

Anyway, just tossing ideas out there...