-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dropping support for non-persistent TimelineStore #41
Comments
sobri909
added a commit
that referenced
this issue
Sep 11, 2018
sobri909
added a commit
that referenced
this issue
Sep 11, 2018
sobri909
added a commit
that referenced
this issue
Sep 11, 2018
sobri909
added a commit
that referenced
this issue
Sep 11, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The main reason why LocoKit 6.0.0 hasn't yet gone final is because some changes along the way during development broke non persistent timeline stores (ie when
TimelineStore
is used instead ofPersistentTimelineStore
).It's been a few months, and I still haven't had a spare moment to fix those regressions. And I've just now started work on a task (that's initially being tracked in the private repo, due to overlapping with some privacy considerations) that will further worsen the situation for non persistent stores.
I dearly want to keep the non persistent stores. But time constraints and limited resources are making it impractical to cover that much breadth and quasi-duplication of functionality. So something has to give.
What that means (probably) is that the
LocalStore
optional subspec will get renamed toTimelines
, and all timeline recording functionality (eg Visits, Paths, TimelineStore, TimelineProcessor, etc) will move into that subspec, and will require the persistent SQL database, thus the GRDB dependency.It also means that ActivityTypeClassifier and friends will also move into the
Timelines
subspec and require the SQL store. (The reason for that being that the current task I'm working on is a migration of activity type ML models from in-memory cache to persistent SQL storage. Semi related to #34).The main LocoKit spec will still provide LocomotionManager and its associated helpers, for recording of Kalman filtered and dynamically smoothed LocomotionSamples, as well as the existing low level, real time moving/stationary state detection. So that low level functionality will continue to be available without needing an SQL store. Thus LocomotionManager will still be easily available as a "CLLocationManager on steroids", for producing cleansed, sanitised location and locomotion samples, with real time moving/stationary state detection.
The new
Timelines
subspec will then provide TimelineRecorder, TimelineStore, etc, for producing high level Visits and Paths, the activity types ML classifier, and the rest of the high level goodies, while depending on GRDB for its SQLite based persistent store.Todos
The text was updated successfully, but these errors were encountered: