Skip to content
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

Open
1 of 2 tasks
sobri909 opened this issue Sep 11, 2018 · 0 comments
Open
1 of 2 tasks

Dropping support for non-persistent TimelineStore #41

sobri909 opened this issue Sep 11, 2018 · 0 comments
Assignees
Milestone

Comments

@sobri909
Copy link
Owner

sobri909 commented Sep 11, 2018

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 of PersistentTimelineStore).

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 to Timelines, 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

  • Reshuffle the classes
  • Document the changes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant