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

hCalendar input/output #19

Closed
macosforgebot opened this Issue Aug 16, 2006 · 6 comments

Comments

Projects
None yet
2 participants
@macosforgebot
Copy link

macosforgebot commented Aug 16, 2006

@wsanchez originally submitted this as ticket:19


It would be swell if the server could accept hCalendar input and emit hCalendar output, given the right content-type/accept headers. This would help the microformats folks use it to embed calendar data into HTML and so on.

@macosforgebot

This comment has been minimized.

Copy link

macosforgebot commented Aug 16, 2006

@wsanchez originally submitted this as comment:1:⁠ticket:19

  • Description modified
@macosforgebot

This comment has been minimized.

Copy link

macosforgebot commented Aug 16, 2006

@wsanchez originally submitted this as comment:2:⁠ticket:19


The best way to implement that in our server would be to add hCalendar parsing and generation in vobject. I understand that some hCalendar generation work is already underway...

Presumably we're going to want to store the data on disk in one format (I vote for iCalendar). If we allowed the underlying data format to change, we'll need to be sure to add a MIME type property to we know it's type. No, the file extension isn't an acceptable method for determining that. Which brings up another point; if you rewrite an iCalendar file with hCalendar, you'd be unable to change the file extension, so that's a snag there as well. So I think we need only one underlying data format, for sanity. Of course that means a PUT on foo.hcal would contain iCalendar data. Not sure we can win there. Content negotiation, anyone?

So a PUT with hCalendar data will result in iCalendar data on disk. When vobject parses that iCalendar data later and generates hCalendar from it, it will probably not be possible to guarantee that it generates exactly the same bytes we started with. That's something to keep in mind in the context of ETags, which the CalDAV spec is somewhat goofy about (Cyrus will disagree about the goofy).

@macosforgebot

This comment has been minimized.

Copy link

macosforgebot commented Aug 16, 2006

@wsanchez originally submitted this as comment:3:⁠ticket:19

  • Type changed from Defect to Feature
@macosforgebot

This comment has been minimized.

Copy link

macosforgebot commented Aug 18, 2006

drernie@… originally submitted this as comment:4:⁠ticket:19


Yes, vObject: http://vobject.skyhouseconsulting.com/epydoc/public/vobject-module.html

is adding microformat generation in the latest build:

<http://svn.osafoundation.org/vobject/trunk/>

and I've pointed them to the Python parser for consumption:

http://microformats.org/discuss/mail/microformats-dev/2005-November/000037.html

I agree you need to normalize the on-disk format, but my main goal is to make it easty to get an hCalendar feed -- ideally with a cool stylesheet. :-)

@macosforgebot

This comment has been minimized.

Copy link

macosforgebot commented Sep 12, 2006

@wsanchez originally submitted this as comment:5:⁠ticket:19

  • Status changed from new to assigned
@macosforgebot

This comment has been minimized.

Copy link

macosforgebot commented Apr 6, 2015

@wsanchez originally submitted this as comment:25:⁠ticket:19

  • Status changed from assigned to closed
  • Resolution set to Not to be fixed

Expiring old bugs with unknown impact

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