Open csandman opened 1 year ago
Hey thanks for asking. It would be cool to have a more opinionated / helpful layer to this. The libraries stated purpose is to be a serializer / deserializer and not much else. I think it has bad DX (developer experience) right now - because I haven't really added anything that helps the developer, a good api, documentation, etc. I had been thinking about creating a new repo or creating a util/
folder which would wrap this library which would preform that purpose.
I think the size of the library has helped people come in and contribute which has helped me a lot with maintaining it. I am open to the idea of changing it but I do want to keep the "predictable dumbness" of the main interface or to increase the size by including embedded files.
It's definitely in scope that the library correctly parses the files, and I wouldn't reject on principle a helper/util package. I'm open to further discussion too. (I would also like a better DX.)
Launched(?) the discussions tab https://github.com/arran4/golang-ical/discussions/75
Thanks for the response! I understand the desire to not overcomplicate the base package for sure. On the note of a util package that wraps this library, that reminded me of something else I've been wondering. Is there a way to set custom properties on a calendar or event? I wasn't really able to find one, and it seems like it would be important for setting X-*
properties that are platform specific. Additionally, if I wanted to add the VTIMEZONE
stuff manually, there would need to be a way to add a BEGIN
block. I'm not sure if these are possible with this library the way it is now or if those are things that would need to be exposed as public APIs.
If you produce a util library a PR to update the read me suggesting it / mentioning it would be reviewed.
The underline way everything is represented in string, so you can just wrap it:
Because it's just a representation of the file; everything is publicly exposed: https://github.com/arran4/golang-ical/blob/f69e132f2b0c9c73cff9ce88c3d6cc1af4bc3e2d/components.go#L21
However some helper functions for experimental / custom API would probably help others and I hope be appreciated. I presume you have some vision for a way which would be easy to use and generalize-able?
I know this comment doesn't add a whole lot to the discussion, but
I think it has bad DX (developer experience) right now - because I haven't really added anything that helps the developer, a good api, documentation, etc.
This feels very true for me right now. I'm new to ICS files - I've used them here and there with feeds to connect my calendar up, but until now I have never used or looked at their content.
It's very confusing, and since this is the first library that comes up, I assumed it would do what I need to do. Almost none of the functions I've seen so far are helpful [in learning it], and trying to learn the ICS format while just trying to accomplish the task I want - it's not easy.
I'm thinking of just creating an ICS file in Google Calendar, exporting it, and using fmt.Sprintf
with a couple of specifiers to get the job done - it'd be much faster, and I don't have to fool around with this ICS package.
Right now, my problem involves getting the timezones figured out. It's nothing complicated, but it seems impossible to do what I need with this package at the moment.
I'd like to help out, but I'm a new Go developer, and I don't know that my opinions or contributions would align with the stated interest(s) of the project. At minimum, the thing that would help me (and perhaps most other simple developers) is having good documentation and examples. How do you accomplish and use this package effectively in your workflow(s)?
Yeah I completely understand that and you're right to feel that way. It doesn't do anything to help onboard people, and has the expectation that the user knows ICS. Mostly because I wrote it for something else I needed where I needed to learn ICS in-order to do it.
I think some more examples as stated before would help, and expansive function documentation. However I don't have the time to do it, I can definitely review suggestions. I had thought about copy pasting in the RFCs into appropriate sections too to make it easier.
@Xevion I would be happy for contributions and I will (be thankful but) push back where I think it exceeds the "scope" of the project.
@Xevion Is this a step in the right direction https://github.com/arran4/golang-ical/pull/107 ?
Part of the issue is that timezones are stored on properties per line item there is no overall "timezone" but you can add them.. I don't recall if there is any global one. But given how complex there is, there might be?
In the ical you can sort of see it here: https://github.com/arran4/golang-ical/issues/97#issuecomment-2381335580
The examples create a timezone for berlin, then it's used in the following event.
I only recently started looking into generating .ics files for a project at work where I'm creating event calendar files to include with tickets for a show in an email. One thing I've seen in my research is including
VTIMEZONE
info in their calendar files to indicate the original timezone the event is in. Here's an example from an exported Google Calendar:There is a standard set of these timezones that come from https://www.tzurl.org/ that cover all standard IANA timezone codes, and it would be really cool if there could be some functionality in this package to set these values based on passing in a code.
I was thinking something along the lines of this right before you make your first
VEVENT
(which I think is the standard place to put it?):Alternatively, you could have some constants set up like
ics.TimezoneAmerica_NewYork
, or use thetime.LoadLocation
functionality:And this would set the start/end and all of the contents of the
VTIMEZONE
info.I've found a couple of node packages that do something similar, and I don't think it would be too difficult to use some of their logic to port their functionality, but I'm also new to Go, so correct me if I'm wrong.
Here's what I found for a similar purpose:
Idk if this is outside the scope of what you'd like to do with this package, but I think it would be a really cool feature to have! I could also look into making a PR for this, but I'd like to get your thoughts first.