New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store metadata about collections in vdir #125

Closed
mistotebe opened this Issue Oct 14, 2014 · 15 comments

Comments

Projects
None yet
4 participants
@mistotebe

mistotebe commented Oct 14, 2014

When performing discovery, vdirsyncer requests the calendar name (displayname), but that is never propagated anywhere. It would be useful to have that name stored alongside the calendar, which would also help the synchronization process as the calendar/addressbook name could then be copied over along its entries.

@untitaker

This comment has been minimized.

Member

untitaker commented Oct 15, 2014

There doesn't seem to be an obvious way for other storages to store this information.

@geier

This comment has been minimized.

Member

geier commented Oct 15, 2014

Do you mean vdir as other storage? a .calendarname file could suffice, couldn't it?

@untitaker untitaker changed the title from Store the calendar/addressbook name to Store metadata about collections Oct 16, 2014

@untitaker untitaker added the mod: DAV label Oct 16, 2014

@untitaker untitaker changed the title from Store metadata about collections to Store metadata about collections in vdir Oct 16, 2014

@untitaker

This comment has been minimized.

Member

untitaker commented Oct 16, 2014

Okay, so in the broadest sense this feature request could be seen as a request to store and sync metadata about the collection. This would be calendar name and color for CalDAV, and, at most, addressbook name for CardDAV. Some thoughts:

  • Using .displayname and .color files would be the way to go IMO. Both are UTF8 encoded.
  • The .displayname file would simply contain the name, not wrapped in JSON or anything like that.
  • The .color file would contain a six-char hexcode.
  • Badly written clients would recognize those files as items, but i think that shouldn't matter.
  • Applications like khal would have to support reading color and calendar name, otherwise this would be useless. Not sure how khal would translate hexcodes to valid terminal colorcodes though.
  • As always, not sure about server support. I am especially pessimistic about writing any changes back to the server.
@mistotebe

This comment has been minimized.

mistotebe commented Oct 16, 2014

Yes, that was what I was thinking about. Regarding your concerns on server support, OX seems to be quite good at this and I while I haven't tested with cyrus imapd, the community is very keen on implementing things properly.

@untitaker

This comment has been minimized.

Member

untitaker commented Nov 26, 2014

JFTR, I think this feature would require a leap from khal's side (or any app other than vdirsyncer), as it's currently khal's business to deal with calendar colors and names.

@WhyNotHugo

This comment has been minimized.

Member

WhyNotHugo commented Apr 3, 2015

Using .displayname and .color files would be the way to go IMO. Both are UTF8 encoded.

I like the idea of having the displayname and colour in files, but I don't see a need for them to be dotfiles. Merely displayname and colouris ok (and does not conflict with the current vdir spec).

The .color file would contain a six-char hexcode.
Applications like khal would have to support reading color and calendar name, otherwise this would be useless. Not sure how khal would translate hexcodes to valid terminal colorcodes though.

I'd opt to using some library that deals with this functionality. Remember that different terminals may have different colour capabilites (16 colours, 256 colours, etc), so there's a need to round the colour to the closest thing available in terminals (I dislike the idea of limiting ourselves to those colours only because it limits functionality for non-terminal apps).


Not sure how we'd deal the the colour been synced. I know that displayname is a calendar property, but do we have custom properties we can use to store the colour?

@untitaker

This comment has been minimized.

Member

untitaker commented Apr 3, 2015

I like the idea of having the displayname and colour in files, but I
don't see a need for them to be dotfiles. Merely displayname and
colouris ok (and does not conflict with the current vdir spec).

That's fine too.

I'd opt to using some library that deals with this functionality.
Remember that different terminals may have different colour capabilites
(16 colours, 256 colours, etc), so there's a need to round the colour
to the closest thing available in terminals (I dislike the idea of
limiting ourselves to those colours only because it limits
functionality for non-terminal apps).

I think we should encode colors as rgb value (e.g. hexcode) because otherwise graphical applications will loose this metadata when unable to express their whole colorspace.

Terminal applications can round to the nearest colorcode. The reverse (encoding to a rgb value that would round down to a specific colorcode) should also be possible.

Regarding the implementation: You might want to take a look at colorama, and at the various image renderers that exist for the terminal (since those have to round down color values too)

Not sure how we'd deal the the colour been synced. I know that
displayname is a calendar property, but do we have custom properties we
can use to store the colour?

Yes, it's pretty standard.

@WhyNotHugo

This comment has been minimized.

Member

WhyNotHugo commented Apr 3, 2015

I think we should encode colors as rgb value (e.g. hexcode) because otherwise graphical applications will loose this metadata when unable to express their whole colorspace.

Terminal applications can round to the nearest colorcode. The reverse (encoding to a rgb value that would round down to a specific colorcode) should also be possible.

That's what I meant.

python-colour doesn't seem to be of use (for clients like khal), regrettably. Dunno if there's something already done to round rgb -> term. colorama doesn't seem to take rgb as an input, so I don't think it'll be of use either (someone might want to double check this last one).

@untitaker

This comment has been minimized.

Member

untitaker commented Apr 3, 2015

The ansi package on pypi seems to be capable of this. There seems to be an algorithm in there for converting to the nearest escape sequence too.

On 3 April 2015 19:04:33 CEST, Hugo Osvaldo Barrera notifications@github.com wrote:

I think we should encode colors as rgb value (e.g. hexcode) because
otherwise graphical applications will loose this metadata when unable
to express their whole colorspace.

Terminal applications can round to the nearest colorcode. The reverse
(encoding to a rgb value that would round down to a specific colorcode)
should also be possible.

That's what I meant.

python-colour doesn't seem to be of
use (for clients like khal), regrettably. Dunno if there's something
already done to round rgb -> term.
colorama doesn't seem to take
rgb as an input, so I don't think it'll be of use either (someone might
want to double check this last one).


Reply to this email directly or view it on GitHub:
#125 (comment)

@untitaker

This comment has been minimized.

Member

untitaker commented Apr 3, 2015

colorama still is useful for Windows compat (it can convert ansi output to Win32 calls)

@untitaker

This comment has been minimized.

Member

untitaker commented May 29, 2015

todoman by @hobarrera now reads the color of a collection from a color file. The metadata branch on vdirsyncer documents how the format looks like.

@untitaker

This comment has been minimized.

Member

untitaker commented Jul 5, 2015

I have a rudimentary version with one-way sync running at #227.

I'm not sure if it's a good idea to implement two-way sync.

@WhyNotHugo

This comment has been minimized.

Member

WhyNotHugo commented Jul 5, 2015

IMHO we need two-way sync, because otherwise we don't have how to alter the value on the DAV side (at least not via vdir-clients).

@untitaker

This comment has been minimized.

Member

untitaker commented Jul 6, 2015

Done. I'd merge this as-is, please try.

@untitaker untitaker modified the milestone: 0.6.0 Jul 6, 2015

@untitaker

This comment has been minimized.

Member

untitaker commented Jul 7, 2015

This will be released in 0.6, the docs are somewhat sparse but will be expanded "on demand".

@untitaker untitaker closed this Jul 7, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment