Addressbook improvements, first shot
randy at sermo.net
Wed Oct 4 16:26:22 CEST 2006
yay for addressbook management!
as a thought though, rather than re-work stuff that's already been
created, why not use existing tools. in particular, plaxo. i've been
using it for a while as a sync tool between my treo, thunderbird, &
outlook and by-and-large, it's been great! and they have an API:
and a really nifty widget demo (access address lists from other apps):
but using their (already well-thought out) field set as a guideline
might be a good way to go.
just a couple of thoughts. i love the enthusiasm in this community!
> On Wed, 4 Oct 2006 13:57:52 +0200, "Paul Carrasco" <paul.carrasco at gmail.com> wrote:
>> On 10/4/06, shane at gnative.com <shane at gnative.com> wrote:
>> Yes! I had the same idea when I included the birthdate attribute in the
>> contact profile. Is someone else already working on it?
> Sounds trivial, but I know that would be a cool feature for many, me included.
>> As for the contact image if this is going to be added the we would need to
>>> look at GD/imagemagik for resizing of uploaded images to be added to the
>>> database when creating a contacts.
>> This depends on how we want to manage images:
>> - the KISS solution (keep it simple stupid) is to use a link to an image
>> already hosted on the internet.
> This makes me think of my blog, and how it handles 'Gravitars' by simply displaying an existing one pulled via the author's email address.
> What is a gravatar?
> A gravatar, or globally recognized avatar, is quite simply an 80×80 pixel avatar image that follows you from weblog to weblog appearing beside your name when you comment on gravatar enabled sites. Avatars help identify your posts on web forums, so why not on weblogs?
> more info on it, how to tie it in: http://www.gravatar.com/implement.php -- Pros would be very little lifting on RC's end, but a simple way to lookup user's icons via email addy (which we'll already have)
> Not sure if this would be better/worse than picon, whichever is further along, more reliable in the long run perhaps.
More information about the Dev