[RFE] Mozilla Thunderbird 3.x/4.x needs SHARED ADDRESSBOOKS (network-wide and system-wide)
rsandu
As I was asked in Thunderbird bug #472494, I'm opening a thread here
in order to discuss a proposed feature that I see as urgently needed
in Thunderbird 3.x/4.x: SHARED ADDRESSBOOKS (network-wide and system-
wide).
In a few words - IMHO:
Conceptually, we distinguish two kinds of addressbooks:
- private addressbook - it is used by one user only;
- shared addressbook - are accessible to many users on the network, in
a client/server
manner. A particular case is "shared system-wide", where client and
server reside on the same physical machine.
At present, Thunderbird only deals with private adressbooks. The
absence of shared addressbooks severely limits Thunderbird under other
functional aspects, such as:
- syncronizing Thunderbird addressbook with MOBILE PHONES (Windows
example: like in Nokia PCSuite or Motorola PhoneTools), via a
standardised protocol;
- having a COMMON ADDRESSBOOK for all e-mail clients installed on a
system (please imagine all PIMs on a system sharing a common
information repository, i.e Thunderbird sharing contacts with mutt,
Evolution, etc., without duplication);
- having an ADDRESSBOOK SHARED BETWEEN MANY USERS, read-write (on the
same computer or over the network);
- allowing third-party programs (such as DATA RECOVERY programs, in
crash situations) to read the addressbook;
- easily integrating many Thunderbird clients in the COMPANY'S
INTRANET DIRECTORY, read/write (via LDAP protocol?). So users may
"feed" the company's directory with their own contact data, administer
it, maintain it, etc....
IMHO, what we basically need to establish is:
- a standardised FILE FORMAT (ISO ? W3C ?) for the addressbook - I
guess vCard is the best candidate;
- a fixed (and well-documented) PLACE for the shared addressbooks to
reside on the filesystem (FHS-compliant, see http://www.pathname.com/fhs/).
Example: say /srv/addresbook/ab1 ... /srv/addresbook/abN. This would
allow SO maintainers to take the shared adddressbook into account when
designing SELinux policies, firewalls, permission schemes, etc.
- a standardised protocol to access the addressbook over the network
(LDAP ?);
- a standardised protocol to syncronize the addressbook with a mobile
phone (over cable, Bluetooth, IrDA, etc.) or al least modular
"plugins"/APIs for proprietary phones.
I'll be very glad to hear other opinions about these general design
ideas.
Thanks a lot,
Răzvan
Nikolay Shopik
> Hello,
>
>
> As I was asked in Thunderbird bug #472494, I'm opening a thread here
> in order to discuss a proposed feature that I see as urgently needed
> in Thunderbird 3.x/4.x: SHARED ADDRESSBOOKS (network-wide and system-
> wide).
>
> In a few words - IMHO:
>
> Conceptually, we distinguish two kinds of addressbooks:
>
> - private addressbook - it is used by one user only;
>
> - shared addressbook - are accessible to many users on the network, in
> a client/server
> manner. A particular case is "shared system-wide", where client and
> server reside on the same physical machine.
>
>
> At present, Thunderbird only deals with private adressbooks. The
> absence of shared addressbooks severely limits Thunderbird under other
> functional aspects, such as:
>
> - syncronizing Thunderbird addressbook with MOBILE PHONES (Windows
> example: like in Nokia PCSuite or Motorola PhoneTools), via a
> standardised protocol;
https://bugzilla.mozilla.org/show_bug.cgi?id=303963
> - having a COMMON ADDRESSBOOK for all e-mail clients installed on a
> system (please imagine all PIMs on a system sharing a common
> information repository, i.e Thunderbird sharing contacts with mutt,
> Evolution, etc., without duplication);
I believe LDAP is most convinced way
> - having an ADDRESSBOOK SHARED BETWEEN MANY USERS, read-write (on the
> same computer or over the network);
>
> - allowing third-party programs (such as DATA RECOVERY programs, in
> crash situations) to read the addressbook;
>
> - easily integrating many Thunderbird clients in the COMPANY'S
> INTRANET DIRECTORY, read/write (via LDAP protocol?). So users may
> "feed" the company's directory with their own contact data, administer
> it, maintain it, etc....
https://bugzilla.mozilla.org/show_bug.cgi?id=86405
rsandu
> I believe LDAP is most convinced way
LDAP is by far the best and the most scalable way of keeping directory
information.
However, for flexibility/practical reasons, it has a few major
drawbacks:
1. It is not readly available when one installs Mozilla Thunderbird
Non-technical users expect the addressbook to be available directly,
after they install Thunderbird. Setting LDAP requires that AN
ADMINISTRATOR integrates Thunderbird (LDAP client) în A PRE-EXISTING
LDAP directory (in the company's intranet). A properly designed LDAP
tree is not easy to design and maintain... That's FAR beyond common
user knowledge.
2. It is read-only
LDAP was designed more as a way to GET directory information from a
central repository (company's directory) than that a way to INSERT
data into this directory. What a medium user expects is to be able to
edit/maintain his contactlist directly in Thunderbird, eventually
entering this data in the company's directory (for others to see and
use, as a shared addressbook).
The second approach is more natural, because THE FINAL USER IS THE
ULTIMATE SOURCE OF CONTACT DATA (at least for himself).
3. Modifying the set of fields in the "business card" is unfeasible
for a non-programmer, because it requires a customised LDAP schema.
The set of fields in a pre-made "business card"/Web form is VERY
inflexible (in the same "form", how to properly represent a company
vs. an individual - what is the "Anniversary" of Adobe, Inc. ? ;-) -
various address fields in different countries, anniversaries fixed/
recurrent etc.);
Regards,
Răzvan
Nikolay Shopik
> 1. It is not readly available when one installs Mozilla Thunderbird
>
> Non-technical users expect the addressbook to be available directly,
> after they install Thunderbird. Setting LDAP requires that AN
> ADMINISTRATOR integrates Thunderbird (LDAP client) în A PRE-EXISTING
> LDAP directory (in the company's intranet). A properly designed LDAP
> tree is not easy to design and maintain... That's FAR beyond common
> user knowledge.
We don't need to invent another bicycle don't we? Why we can't just ship
with pre-configured LDAP with some scheme which suites *MOST* cases. If
this is rare case when some company need to special fields and changes
in schema - they should have ask for IT integrator or use their own IT
staff. Because usually these companies are not small already ;)
> 2. It is read-only
>
> LDAP was designed more as a way to GET directory information from a
> central repository (company's directory) than that a way to INSERT
> data into this directory. What a medium user expects is to be able to
> edit/maintain his contactlist directly in Thunderbird, eventually
> entering this data in the company's directory (for others to see and
> use, as a shared addressbook).
> The second approach is more natural, because THE FINAL USER IS THE
> ULTIMATE SOURCE OF CONTACT DATA (at least for himself).
Exactly it was designed to be fast when reading, because mostly you are
reading information from addressbook than writing there.
> 3. Modifying the set of fields in the "business card" is unfeasible
> for a non-programmer, because it requires a customised LDAP schema.
> The set of fields in a pre-made "business card"/Web form is VERY
> inflexible (in the same "form", how to properly represent a company
> vs. an individual - what is the "Anniversary" of Adobe, Inc. ? ;-) -
> various address fields in different countries, anniversaries fixed/
> recurrent etc.);
People using outlook contacts and not seeing such problems. There
already proposed standards by IETF for address book schema using LDAP.
Correct me if I misunderstood you in this.
Mark Banner
> Conceptually, we distinguish two kinds of addressbooks:
>
> - private addressbook - it is used by one user only;
>
> - shared addressbook - are accessible to many users on the network, in
> a client/server
> manner. A particular case is "shared system-wide", where client and
> server reside on the same physical machine.
I've just been reminded, have you seen weave?
http://labs.mozilla.com/2007/12/introducing-weave/
This is a concept where an application's metadata can be pushed into a
"cloud" on a server, and then that can be passed to different instances
of the user's applications (e.g. different OS, different app), or even
allowed to be shared with other people.
Currently the early versions only work with Firefox. We have
experimented with Thunderbird integration although I think it has been
blocked for a while by some other work that we're just about to complete.
The general concept would allow for a user's data to be retrieved
wherever they would like, and would allow for sharing.
Devices could sync with the server, or potentially we could have a local
server running on the machine that they could talk to.
> IMHO, what we basically need to establish is:
I think we need to start with the concepts of what we do, not the
implementation.
Standard8
Peter Lairo
> - a standardised FILE FORMAT (ISO ? W3C ?) for the addressbook - I
> guess vCard is the best candidate;
Would CalDAV or WebDAV work? Is that less difficult than LDAP (which
seems incredibly hard)?
--
Regards,
Peter Lairo
The browser you can trust: www.Firefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Islam - Myths & Facts: http://www.jihadwatch.org/islam101/
Israel - Myths & Facts: http://www.JewishVirtualLibrary.org/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Nikolay Shopik
> Would CalDAV or WebDAV work? Is that less difficult than LDAP (which
> seems incredibly hard)?
Calendar data.
Peter Lairo
I thought there was some kind of "DAV" that could be used to share just
about any kind of data. :-\
farmer...@gmail.com
> discuss a proposed feature that I see as urgently needed
> in Thunderbird 3.x/4.x: SHARED ADDRESSBOOKS (network-wide
> and system-wide).
I'm with rsandru on his basic ideas regarding online/shared address
books. While I probably couldn't write enough code to get me out of a
paper bag, this is an area of keen interest to me from the standpoint
of workgroup collaboration.
I would like Thunderbird to provide the ability to do the same kinds
of things with contacts as can currently be done with calendars.
Currently, with the iCal format, Lightning, and the "Provider for
Google Calendar" extension, I have the following:
1. Online and offline read/write access to my Google calendars via
Thunderbird
2. The ability to sync these calendars.
3. The ability to designate entire calendars -- and specific events --
as 'private' or 'public'.
4. Online access to these calendars outside of Thunderbird, via the
web.
5. Read-only access to public Google calendars, or to Google calendars
for which I've been given access, both through Thunderbird and the
web.
6. The ability to grant others access to my online calendars.
I wish I had a similar ability with contacts -- and for me (and other
users) to be able to set up and administer an online system for
sharing them similar to what can be done with calendars.
Here's how I'm handling this currently. Recently I came across PHP
iAddressbook (http://iaddressbook.org/). This is a cute little web
app that creates a MySQL (or SQLite) database from a vCard file. It's
designed as a single-user database, but I suppose it could be modified
to tag each record with an 'owner' and with record-level access
controls regarding read/write privileges.
By exporting my .mab files to vCard format (using the
MoreFunctionsForAddressBook extension) and importing the vCard file to
my PHP iAddressbook installation on the web, I get a way of cloning my
local addressbooks and having access to them via the web. But this is
a clumsy, manual process, there's no ability for true synchronization,
and, as mentioned, iAddressbook isn't currently set up with multiusrer
access in mind.
(As an aside, I happen to like php iAddressbook's UI, which emulates
Apple's AddessBook.app, and is quicker and easier to use for creating
or editing contacts than the 5-tabbed Thunderbird contact edit
window.)
My 2 cents.
Pete Farmer
Nikolay Shopik
> I thought there was some kind of "DAV" that could be used to share just
> about any kind of data. :-\
just end up in deciding which format to store address book. And probably
many other things when you are sharing this file among others people.
That's why iCal don't use basic WebDAV and there special version of CalDAV.
Joshua Cranmer
> 1. Online and offline read/write access to my Google calendars via
> Thunderbird
> 2. The ability to sync these calendars.
> 3. The ability to designate entire calendars -- and specific events --
> as 'private' or 'public'.
> 4. Online access to these calendars outside of Thunderbird, via the
> web.
> 5. Read-only access to public Google calendars, or to Google calendars
> for which I've been given access, both through Thunderbird and the
> web.
> 6. The ability to grant others access to my online calendars.
>
> I wish I had a similar ability with contacts -- and for me (and other
> users) to be able to set up and administer an online system for
> sharing them similar to what can be done with calendars.
Have you heard of pi's gContactSync? This sounds like it would do most
of what you want to do.
<http://gcontactsync.mozdev.org/>
rsandu
> On 09.01.2009 10:42, rsandu wrote:
>
> > 1. It is not readly available when one installs Mozilla Thunderbird
>
> > Non-technical users expect the addressbook to be available directly,
> > after they install Thunderbird. Setting LDAP requires that AN
> > ADMINISTRATOR integrates Thunderbird (LDAP client) în A PRE-EXISTING
> > LDAP directory (in the company's intranet). A properly designed LDAP
> > tree is not easy to design and maintain... That's FAR beyond common
> > user knowledge.
>
> We don't need to invent another bicycle don't we? Why we can't just ship
> with pre-configured LDAP with some scheme which suites *MOST* cases. If
> this is rare case when some company need to special fields and changes
> in schema - they should have ask for IT integrator or use their own IT
> staff. Because usually these companies are not small already ;)
>
I think that, in itself, the LDAP protocol is the *perfect* vehicle
for storing and manipulating addressbooks, but it's a loooong way to
go till we can have a *practically usable* implementation for small
offices and home users.
I'll be very happy to download Thunderbird and find there, directly in
the package, a small preconfigured LDAP server and a friendly UI for
inserting my contacts. If all this is well-documented, later I'll be
able to link (share) this to:
- user John Doe which is using the same computer as I do (locally,
with no network connection);
- an user in the office down the hall or in another town (over LAN or
WAN);
In the mean time, other third-party tools will show up on the market,
allowing me to *easily* back-up this data, export it to other formats
(.vcf), etc.
IMHO, Thunderbird shouldn't be designed with the starting idea of
external developers/integrators, big companies, customizations, etc.
They simply don't exist in 99,99% practice. The golden rule says: "90%
of the users will use the DEFAULT OPTIONS/CODE and nothing more".
Please look on the market today...
The ultimate bet/goal here is Thunderbird acceptance on the market,
*practical* usage, Outlook competition, refining unfriendly rough ends/
non-commercialsms/hackerisms, etc. Our target user is a non technical-
user, the brainless, non-IT-educated "new man" created by present
Microsoft technologies. IMHO, we have to invest MUCH MORE attention
in that - as a marketing goal for Thunderbird !
> > 2. It is read-only
>
> > LDAP was designed more as a way to GET directory information from a
> > central repository (company's directory) than that a way to INSERT
> > data into this directory. What a medium user expects is to be able to
> > edit/maintain his contactlist directly in Thunderbird, eventually
> > entering this data in the company's directory (for others to see and
> > use, as a shared addressbook).
> > The second approach is more natural, because THE FINAL USER IS THE
> > ULTIMATE SOURCE OF CONTACT DATA (at least for himself).
>
> Exactly it was designed to be fast when reading, because mostly you are
> reading information from addressbook than writing there.
>
Sorry, but I think this is a huge conceptual/design mistake (not for
the LDAP protocol itself, but for the way you'd use it in the above
scenario).
As I said, the ultimate source of contact data is the final user
itself, not the IT or the HR departments. Data should be collected/
integrated in a directory MUCH more quickly if we allow the final user
to (easily) enter it.
That means that the addressbook part in Thunderbird becomes, in fact,
a small LDAP editor for an (inflexible) predefined schema -> painfully
to develop and maintain, especially when one tries to modify the
default LDAP schema.
Maybe using vCard or some sort of XML language for the local
addressbook (i.e. with easily CUSTOMIZABLE fields), with the option to
export it in LDAP *afterwards* (just when one tries to integrate the
local AB in the company's directory) is a more realistic design option
for Thunderbird.
> > The set of fields in a pre-made "business card"/Web form is VERY
> > inflexible (in the same "form", how to properly represent a company
> > vs. an individual - what is the "Anniversary" of Adobe, Inc. ? ;-) -
> > various address fields in different countries, anniversaries fixed/
> > recurrent etc.);
>
> People using outlook contacts and not seeing such problems. There
> already proposed standards by IETF for address book schema using LDAP.
> Correct me if I misunderstood you in this.
As I said above, people using Outlook does a simple thing: USE
DEFAULTS that are ENFORCED on them (by Microsoft). Usually they don't
like them, but they have no alternative. In time, they become so
accustomised to these habits, that lare ready to kill to preserve
them ;-) Even raise those habits at ISO level...
In free software, we are talking about other kind of concepts here:
find an OPTIMISED solution, yet minimalistic and modular.
Best regards,
Răzvan
rsandu
wrote:
> I've just been reminded, have you seen weave?http://labs.mozilla.com/2007/12/introducing-weave/
Thank you, Mark, I've skimmed over weave for a little...
I think it's great (REALLY!), but it's simply other class of
application:
- users don't like relaying on network access for having grandma's
telephone number at hand (I'm in the mountains and I want to call her
without needing data/3G access, so I HAVE to have her number LOCALLY
on my cellphone/laptop);
- users are unconfortable of submitting large quantities of personal
data to EXTERNAL, online providers, no matter how reliable/trustfull
they are (remember the sexy pictures of your girlfriend that you took
last holiday ;-) ? )
- online services (that imply a working laptop, a valid account and a
minute-billed network link) have a limited scope in their very
definition. Individuals tend to prefer the *simplest* way of access to
their data (ideally, their own physical capabilities, their own body).
If in doubt, think why modern PDAs (which offer access to quickly
reusable information, in electronic format) never displaced paper and
pencil.
- electronic data is painfully volatile. The papirus manuscripts of
the Bible lasted for 2000 years, but I have to have multiple,
attentively conserved backup copies of my camera photos, to be able to
see them after 15 years .
Regards,
Răzvan
Andrew Sutherland
> - users don't like relaying on network access for having grandma's
> telephone number at hand (I'm in the mountains and I want to call her
> without needing data/3G access, so I HAVE to have her number LOCALLY
> on my cellphone/laptop);
Weave uses the network to synchronize. Your information always exists
locally. No network = no updates, but you still have what you already
synchronized (or entered/modified yourself.)
> - users are unconfortable of submitting large quantities of personal
> data to EXTERNAL, online providers, no matter how reliable/trustfull
> they are (remember the sexy pictures of your girlfriend that you took
> last holiday ;-) ? )
Data stored in weave is encrypted by the client and stored in an
encrypted form on the server. In other words, the server never sees
your pictures in a usable form, at least as long as you choose a good
pass-phrase. I think as weave grows more features this may be slightly
relaxed, but client-side encryption/decryption is a big feature for them.
Andrew
Joshua Cranmer
> - users don't like relaying on network access for having grandma's
> telephone number at hand (I'm in the mountains and I want to call her
> without needing data/3G access, so I HAVE to have her number LOCALLY
> on my cellphone/laptop);
It's a synchronization service--no network access means that you can't
update your information across computers.
> - users are unconfortable of submitting large quantities of personal
> data to EXTERNAL, online providers, no matter how reliable/trustfull
> they are (remember the sexy pictures of your girlfriend that you took
> last holiday ;-) ? )
Social networking sites are very powerful counterexamples. Also look at
the problem of social engineering in phishing scams: if anything, users
are too ready to release private, personal information.
> - electronic data is painfully volatile. The papirus manuscripts of
> the Bible lasted for 2000 years, but I have to have multiple,
> attentively conserved backup copies of my camera photos, to be able to
> see them after 15 years .
If you're complaining that data is all too easy to lose, keep in mind
that keeping a copy with a web service is probably going to be far more
reliable than anything on a home computer; even small corporations
regularly back up data, whereas the average home user never backs it up.
Mark Banner
On 01/09/2009 21:31, rsandu wrote:
> - online services (that imply a working laptop, a valid account and a
> minute-billed network link) have a limited scope in their very
> definition. Individuals tend to prefer the *simplest* way of access to
> their data (ideally, their own physical capabilities, their own body).
> If in doubt, think why modern PDAs (which offer access to quickly
> reusable information, in electronic format) never displaced paper and
> pencil.
There's nothing to say you that Thunderbird couldn't be set up with a
local server, indeed, you can set up weave to run as your own server
(although I've not tried that).
> - electronic data is painfully volatile. The papirus manuscripts of
> the Bible lasted for 2000 years, but I have to have multiple,
> attentively conserved backup copies of my camera photos, to be able to
> see them after 15 years .
If you back up carefully, then surely you back up your profile/user data
as well?
Standard8
AC
> On 09.01.2009 7:21, rsandu wrote:
>> - a standardised FILE FORMAT (ISO ? W3C ?) for the addressbook - I
>> guess vCard is the best candidate;
>
> Would CalDAV or WebDAV work? Is that less difficult than LDAP (which
> seems incredibly hard)?
Maybe you're thinking along the lines of vCardDAV (CardDAV).
http://www.ietf.org/html.charters/vcarddav-charter.html
http://www.vcarddav.org
rsandu
Users always complained about Microsoft Outlook keeping addressbook
data in a proprietary file format (the famous .pst file). WHY is that?
IMHO, that's because people need utilities to read/write that
addressbook outside the program itself - backup it, move it, share it
with other users locally and/or over the network, etc. ?
At present, Thunderbird 2.x's adressbook is a kind of information
island: it can't be syncronised with a mobile phone, can't be shared
among users, etc.
I would LOVE to have, on my (Fedora) system, a COMMON, non-duplicated
addressbook for Thunderbird, mutt and Gnome Evolution (read-write),
without needing network access/online syncronization services.
Do you see a simple solution for that (for my non-technical users) ?
Regards,
Razvan
Joshua Cranmer
> I would LOVE to have, on my (Fedora) system, a COMMON, non-duplicated
> addressbook for Thunderbird, mutt and Gnome Evolution (read-write),
> without needing network access/online syncronization services.
Then you'll either be wanting the bug to support access to libebook or
the bug to become a libebook provider. Neither of which look likely to
make it to TB 3 due to lack of time.
rsandu
> Then you'll either be wanting the bug to support access to libebook or
> the bug to become a libebook provider. Neither of which look likely to
> make it to TB 3 due to lack of time.
Hello,
Sounds enormously interesting !
For me, it doesn't matter that it can't make into the first version of
TB3. What *does* matter is that the project exists and it will be
included in Thunderbird after some time.
Is there any hope that this common addresssbook will be syncronised
with mobile phones, via cable, IrDA or Bluetooth, too ? If yes, this
is a HUGE step forward, IMHO.
Răzvan
Dan Mosedale
> On Jan 11, 4:27 pm, Joshua Cranmer<Pidgeo...@verizon.net> wrote:
>
>> Then you'll either be wanting the bug to support access to libebook or
>> the bug to become a libebook provider. Neither of which look likely to
>> make it to TB 3 due to lack of time.
>
> For me, it doesn't matter that it can't make into the first version of
> TB3. What *does* matter is that the project exists and it will be
> included in Thunderbird after some time.
To me, libebook feels like a local optimization in the sense that the
set of people it's likely to help is confined to Evolution users, and
they are mostly Linux users.
The more leveraged solution to the data island issue would appear to be
Portable Contacts <http://portablecontacts.net/>, which uses a vCard
model mapped to JSON and XML. The leverage comes from the fact that
it's much webbier, and it's being embraced by players in the web space
that serve enormously large groups of users.
Dan
Martin Dragt
Talking about collaboration: what I would be looking for, assuming TB is -for
now- basically (but not only) used in small environments, homes and other
groups:
- Read Only access to a directory with protected contact details of me and
my colleagues / housemates / primary group members. I should be able to edit
my personal contact details from within TB and 'update' these in the shared
directory. Also the group's directory administrator (which could be the same
person on a stand alone system) can edit contact details. I would prefer to
integrate/combine this with LDAP access to the same directory that can be
used to configure user accounts (allowing access to the network);
- Read / Write access to directories with contact details of anyone that I
and my colleagues / housemates / group members wish to share. Entries in
this directory may be edited by anyone having access to the group. It should
be possible to participate in zero to multiple additional groups.
- The directories should be usable off-line, and synched with the online
version if accessible;
- I would also be looking for a directory that can hold multiple addresses
(visiting, postal, invoicing, home, work etc), phone numbers (fixed line,
mobile, fax, work, home), email addresses (work, home) per contact. The data
fields should respect international differences: a Dutch address/phone
number layouts are not similar to US or UK layouts.
Hope this inspires someone.
Kind regards
Martin Dragt
--
View this message in context: http://www.nabble.com/-RFE--Mozilla-Thunderbird-3.x-4.x-needs-SHARED-ADDRESSBOOKS--%28network-wide-and-system-wide%29-tp21366916p22214753.html
Sent from the Mozilla - Thunderbird mailing list archive at Nabble.com.
Ben Bucksch
> To me, libebook feels like a local optimization in the sense that the
> set of people it's likely to help is confined to Evolution users, and
> they are mostly Linux users.
Agreed.
Good would be another standard for the local computer, even if it's a
different one for MS, Mac and Linux each.
vCardDAV seems like a good idea, too, if I want to have it on a server
(home, company).
> The more leveraged solution to the data island issue would appear to
> be Portable Contacts <http://portablecontacts.net/>, which uses a
> vCard model mapped to JSON and XML. The leverage comes from the fact
> that it's much webbier
It also has the downside that all my contacts are then at a third party
company.
Who your friends are is very valuable information about a human. ("Tell
me who you are with, and I tell me who you are.")
I fundamentally resent the basic idea to share between two of my own
devices via a third party.
I am aware that it's currently considered "in" and "cool", but that
doesn't change the fundamental facts.
Dan Mosedale
> On 12.01.2009 20:31, Dan Mosedale wrote:
>> To me, libebook feels like a local optimization in the sense that the
>> set of people it's likely to help is confined to Evolution users, and
>> they are mostly Linux users.
>
> Agreed.
>
> Good would be another standard for the local computer, even if it's a
> different one for MS, Mac and Linux each.
Perhaps "call an OS API that gives back contact information in PoCo
JSON/XML" could be that standard.
> vCardDAV seems like a good idea, too, if I want to have it on a server
> (home, company).
Assuming vCardDAV sees broad adoption, that is worth considering too.
>> The more leveraged solution to the data island issue would appear to
>> be Portable Contacts <http://portablecontacts.net/>, which uses a
>> vCard model mapped to JSON and XML. The leverage comes from the fact
>> that it's much webbier
>
> It also has the downside that all my contacts are then at a third party
> company.
>
> Who your friends are is very valuable information about a human. ("Tell
> me who you are with, and I tell me who you are.")
>
> I fundamentally resent the basic idea to share between two of my own
> devices via a third party.
To some degree, I agree with most of the things you've said above.
However, there's nothing about Portable Contacts that implies you
shouldn't run your own personal PoCo compliant server, and part of the
appeal of the spec is that it's simple enough that such a server should
be easy to write. Additionally, one could certainly use the JSON/XML
data model of Portable Contacts (which is mostly semantically equivalent
to vCard + updates + extensions) locally without necessarily entraining
HTTP.
For encrypted cloud-based storage, it could be interesting to do some
experimentation around composing Portable Contacts and Weave, as they
feel compatible in many ways.
Dan