[9front] ical and vcard

[9front] ical and vcard

[Steve Simon]

hi,

i am toying with the idea of integrating ical/caldav and vcard/carddav support into plan9.

the obvious way to do this is to create file servers so local contacts and calendar events could be merged with remote ones using standard plan9 bind rules (before/after/replace).

the problem is plan9 stores contacts in various places (/adm/keys.who, /mail/box/$user/names, and /lib/tel, calendars live in $home/lib/calendar.

for such an approach i would have to create a new contact and calendar database.

so, what do you think? horror, why not? maybe you have a better approach?

-Steve

Re: [9front] ical and vcard

[Stanley Lieber]

On December 6, 2020 5:56:58 PM EST, Steve Simon <steve@quintile.net> wrote:
>
>hi,
>
>i am toying with the idea of integrating ical/caldav and vcard/carddav support into plan9.
>
>the obvious way to do this is to create file servers so local contacts and calendar events could be merged with remote ones using standard plan9 bind rules (before/after/replace).
>
>the problem is plan9 stores contacts in various places (/adm/keys.who, /mail/box/$user/names, and /lib/tel, calendars live in $home/lib/calendar.
>
>for such an approach i would have to create a new contact and calendar database.
>
>so, what do you think? horror, why not? maybe you have a better approach?
>
>-Steve
>

part of this is backed by a bounty:

 vcardfs $5
File system for vCard files, preferably read AND write. sl will actually pay for this. 

sl

Re: [9front] ical and vcard

[ori]

Quoth Steve Simon <steve@quintile.net>:
> 
> hi,
> 
> i am toying with the idea of integrating ical/caldav and vcard/carddav support into plan9.
> 
> the obvious way to do this is to create file servers so local contacts and calendar events could be merged with remote ones using standard plan9 bind rules (before/after/replace).
> 
> the problem is plan9 stores contacts in various places (/adm/keys.who, /mail/box/$user/names, and /lib/tel, calendars live in $home/lib/calendar.
> 
> for such an approach i would have to create a new contact and calendar database.
> 
> so, what do you think? horror, why not? maybe you have a better approach?

I don't think any of the current user information formats
are sacred, and it's likely that we can do something that
fits our needs better.

There's also the alternative of consuming those sources in
your vcardfs and merging them in to the new location.

Or some mix of the two.

But this is a proposal to propose changes -- I'll need
to see the proposed new world before I can opine on it.