Contacts/Calendar discussion?

[Dave Cridland [Home]]

On Mon, 2004-03-29 at 16:57, Nicos Gollan wrote: 
> On Fri, 26 Mar 2004 23:05:29 +0000
> "Dave Cridland [Home]" <dave at cridland.net> wrote:
> 
> > I'd mention ACAP, but then, I always do. :-)
> 
> That looks nice but there doesn't seem to be an implementation
> available?

Yeah, I wrote one. http://infotrope.clues.ltd.uk/ when the server is
actually working. (When I say "server", I mean my workstation.) If you
hang on a couple of weeks, I'll have the newer, shinier version out, but
the version that's there should be pretty useful.

> > Naturally, not everyone will want to run an ACAP server, or indeed an
> > LDAP server or anything.
> 
> The main problem I see with LDAP currently is that it is a true nerd's
> plaything with very little clear documentation on the Web (some lengthy
> searching got me two tutorials that half-heartedly explained how to do
> user authorization and some hundred sites telling me to buy a book).
Yeah, there does seem to be plenty of money out there for people who
really figure out LDAP. 
> If there was a simple to maintain little server or daemon running
> somewhere that allowed each user to store its addressbooks, cooking,
> recipies, calendars and other information without having to go through
> tons of dead trees, that'd be a great thing.

Yeah, except that LDAP isn't really designed for that - it's designed
for The Addressbook, The Cookbook, etc. Site-wide, authoritative
directory stuff. ACAP's designed for personal scope data, optionally
with sane defaults, and user-orientated sharing of data. Most ACAP
servers should, in principle, be easy to manage, as there's no
hard-defined schemas to get in the way.

LDAP == The Telephone Directory.
ACAP == Those notebooks and scraps of paper lying about with your mates'
numbers scrawled down in, plus random notes like "** good plumber**",
and strange highlighting in yellow done by your hyper-organised wife,
which you don't understand, but she does.

[Yes, I do have a hyper-orgnised wife, and more amazingly yet, a good
plumber.]

This isn't so much personal opinion, this is what the two systems were
designed, from the bottom up, for. (Admittedly, ACAP was designed with
addressbooks and general configuration information in mind, rather than
just an X.500 directory, but you get the idea.)

> Does ACAP allow for user-defined storage classes and ad-hoc extensions
> of existing ones? For example, if a mail client absolutely had to store
> an identity to post as for some addressbook entries, could it define a
> field like "X-SomeClient-MailAs: Masked Stranger"?

Yes, indeed, to both.

Actually, it's slightly better than that. My client would, if I
implemented such a thing, say:

"vendor.infotrope.personality" "/personality/~/masked-stranger"

The bit on the left is the attribute name, prefixed with my vendor
prefix to avoid namespace clash, and the bit on the right is an ACAP
relative URL pointing to the (draft) personality entry to use.
(Typically, it could be a full ACAP URL, as well.)

You could also use "user.nicos." as a prefix, for truly user-defined
extensions.

> > Strikes me that we need an environment variable and/or file with a
> > list of URLs in, and some schemes defined which adequately describe
> > what to do with local files. (Prepended with 'x-' to indicate they're
> > non-standard, of course.)
> 
> What we also need is some minimum standard a client conforming to
> some spec needs to understand. There is no such standard.
I did think, rereading my own witterings, that the file actually needs
to be in a similar format to gconf's path file - which is, roughly:

<gconf backend to use>:<some flags, like "readonly">:<single line
address, possibly a URI, for backend to use> 
Meaning that we could say:

acap::acap://myuser;AUTH=*@acap.example.net/addressbook/~/
ldap:readonly:ldap://yikes.i.do.not.know.how.to.write.ldap.urls/
vcard-dir:readonly:/usr/share/addresses/
vcard-dir:dirlockfile=Lock:~/addresses/
For example. (And yes, I am making these up, although the ACAP URL is
legit.) 
It's quite a nice format, as it stops people having to invent schemes
(Pet hate of mine), instead providing us with a different namespace
field we can run a registry for inside XDG. 
We don't really need a minimal base standard, since I certainly don't
want all my possible remote addresses copied laboriously into local
storage for less capable clients, and my impression of current
strategies for storage and access of contact information is that there's
room for the kind of "arms race" that happened to mailbox storage
formats a while back. 
Hopefully, clear winners will come out, and lessons can be learned, and
we'll end up hosting a set of specifications or pointers to them for
*good* ways of storing and accessing addressbooks later on down the
line, and from there potentially reference implementations. 
> > Calendaring should probably go the same route, I think - if CAP ever
> > comes out, being able to specify that that's where your schedule is
> > could be very useful. I doubt SoHo users are likely to run a CAP
> > server anytime soon, though, so I would imagine filesystem-based
> > solutions will be the norm here for a while. At least unless I get my
> > way.
> 
> What about a "standard" library that handles access to several sources
> and can be configured to take its data from local per-user storage, a
> local or remote CAP server or line static from the microphone input?
I'll go for the same as the Contacts/Addressbook solution.

Dave.