michael-maltsev
commented
2 years ago I'd rather not add workshop handling to technion-ug-info-fetcher. I prefer to keep the project focused on fetching information in raw form from the UG website. The parsing of workshop information from course comments is fuzzy and is sometimes changed and tweaked. Those tweaks affect all previous semesters, while technion-ug-info-fetcher only runs for the last three semesters (and I want to keep it that way).
In other words, I'd like to keep the separation of concerns:
- technion-ug-info-fetcher exports raw data from the UG website. This data changes when the UG website changes, and doesn't change otherwise.
- Other code (currently the CheeseFork frontend) can do other manipulations and transformations.
If it would be a large scale project, perhaps I'd create a package for technion-ug-info-fetcher artifacts, and then another package for enrichments to share between consumers such as CheeseFork and ttime3. But since CheeseFork is just a small hobby project, many things are organized ad-hoc, good enough for me to keep maintaining the project.
Probably the best solution would be to make the Technion include workshops as part of the regular schedule. Then I won't need to do fuzzy parsing and handle typos and such. But that requires changes that are out of my control.
In https://github.com/lutzky/ttime3/issues/233 we noticed that cheesefork displays workshop info by parsing the comments. For ttime3 to do this as well, I'd either need to duplicate your code, or - better IMO - modify https://github.com/michael-maltsev/technion-ug-info-fetcher to add that information in machine-readable form (my PHP is pretty rusty but it should be figure-out-able). Would that be reasonable? Any preferences?