You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The iCalendar specification only provides a single (but flexible) LOCATION parameter for Event locations. There is also a GEO parameter, but that is for latitude and longitude and can largely be derived from the Location if an address is provided.
This makes the experience of holding a virtual Event feel like a secondary application, since the "Location" is technically a URI (say, to Zoom, Twitch, or elsewhere). URIs are completely valid locations, but it doesn't feel obvious to use it that way.
One Solution
Some other WordPress calendar plugins have used post types for storing Venues for repeat use. This way, the location can be saved one time and picked from a list rather than needing to be reentered each time. I'm uncertain that this exact implementation makes sense for our use (maybe a taxonomy is better?) but I can see why this approach is attractive.
Why?
Our Calendar Feeds add-on would benefit from supporting the VVENUE iCalendar component. It's been in draft status since 2007, but appears to be largely supported by major calendar softwares.
Problem
The iCalendar specification only provides a single (but flexible)
LOCATION
parameter for Event locations. There is also aGEO
parameter, but that is for latitude and longitude and can largely be derived from the Location if an address is provided.This makes the experience of holding a virtual Event feel like a secondary application, since the "Location" is technically a URI (say, to Zoom, Twitch, or elsewhere). URIs are completely valid locations, but it doesn't feel obvious to use it that way.
One Solution
Some other WordPress calendar plugins have used post types for storing Venues for repeat use. This way, the location can be saved one time and picked from a list rather than needing to be reentered each time. I'm uncertain that this exact implementation makes sense for our use (maybe a taxonomy is better?) but I can see why this approach is attractive.
Why?
Our Calendar Feeds add-on would benefit from supporting the
VVENUE
iCalendar component. It's been in draft status since 2007, but appears to be largely supported by major calendar softwares.See: See: https://tools.ietf.org/html/draft-norris-ical-venue-00
The text was updated successfully, but these errors were encountered: