|
|
|
|
|
by grinich
3959 days ago
|
|
Did you release the code to this? It's a really interesting idea! How did you ensure they are deterministic or run in constant time? (Or are they not guaranteed to?) One of our goals with the Nylas calendar APIs was to make them backwards compatible, so that developers could still interact with Gcal/Exchange. This means we're really restricted in what we can expose at this point. Having more sophisticated tools for defining repeating events or moments in time is certainly where we want to go, though! |
|
Complete calendar data and rules are stored as a single text file! that's what i wanted too (about 1MB for 20 years' data). I can make manual backups!
Regarding the exiting formats, i wrote an importer that converts iCal to LUA. Basically, just a set of templates. Indeed the original idea was to offer a UI to people whereby clicking on things would automatically generate bits of LUA generators - sort of non-programmatic interface for non-power users.
For efficiency (deterministic run-time), each generator takes a date and returns a date. So that it always returns a later date than it is given.
The calendar is generated on demand, so today I'm viewing August 2015. If i scroll down to September/October etc. The generators are called until they return dates later than my current view (or stop generating). I can scroll down years and years and everything works fine.
Primitives such as "nextNewMoon" etc can either be coded in LUA as part of initialisation, or added to the internal LUA run-time. The calendar algorithms are all from "Calendrical Calculations" by Nachum-Dershowitz. Although i converted them to C++ (from lisp!).
At some point i need to finished the Chinese calendar :-)