Skip to content
This repository has been archived by the owner. It is now read-only.

hCalendar input/output #19

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

hCalendar input/output #19

macosforgebot opened this issue Aug 16, 2006 · 6 comments

Comments

@macosforgebot
Copy link

@macosforgebot 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
Copy link
Author

@macosforgebot macosforgebot commented Aug 16, 2006

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

  • Description modified
@macosforgebot
Copy link
Author

@macosforgebot 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
Copy link
Author

@macosforgebot macosforgebot commented Aug 16, 2006

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

  • Type changed from Defect to Feature
@macosforgebot
Copy link
Author

@macosforgebot 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
Copy link
Author

@macosforgebot macosforgebot commented Sep 12, 2006

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

  • Status changed from new to assigned
@macosforgebot
Copy link
Author

@macosforgebot 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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.