Coolness! :
Is that a “stable beta”? and does this mean it will work with a Farmier-hosted instance?
Oooh! double-cool. Same question: will this work, when it lands, with Farmier-hosted instance?
Coolness! :
Is that a “stable beta”? and does this mean it will work with a Farmier-hosted instance?
Oooh! double-cool. Same question: will this work, when it lands, with Farmier-hosted instance?
Maybe if we both say “please”?
I’ve been looking forward to the fieldkit too. Very happy about progress and the info.
Sorry, I should have clarified. I vacillated a bit on how to version the Tasks module, b/c in and of itself, it should be more-or-less complete, and I don’t anticipate any changes will be needed prior to Field Kit itself reaching a stable beta, aside from any minor bugfixes that crop up in the intervening time. However… since Field Kit itself is still unstable, I won’t recommend it for active daily use with critical data. So I guess the answer is no, sorry. Same for the Observations module when it’s “done”.
And I’ll further clarify my interpretation of “stable” for Field Kit is that it won’t force users to totally wipe their cache and reinstall it whenever there’s a new release. The main reason for that would be if I needed to make any changes to the underlying schemata Field Kit uses for its local (offline) database. I don’t expect any more changes like that before I get Observations done ( ), but the heaviest lift with that module will be working out a new way to cache images (and other files) together their associated data, and until I do that, I don’t want to get bogged down writing database migrations whenever a schema needs to change.
The other way I’m interpreting “stable” here is in what I’ve referred to as “UX Stabilty” in the above chart. That mainly centers on the overall shift in user experience away from the single monolithic app that v1 represented, toward the more modular paradigm in v2, where all significant features are contained in their own Field Modules and Field Kit itself is relegated to mere scaffolding that deals with the nitty gritty problems of keeping things offline, synced and configured correctly with any given farmOS server. And to my mind, I can’t consider that experience “stable” for users while there are fewer than 2 working modules that can come standard with farmOS & Field Kit. I don’t want to “break” users’ workflows or mental models because they just got used to it being a single module, if that makes sense?
The real achievement with Field Kit beta, I hope, is that other developers can make use of that scaffolding and I won’t have to be a blocker to new features and functionality in the future. At least, that’s the dream!
As a naive user for whom most talk of tech under the hood is incomprehensible, i just want to make sure i understand something about data stores & flows between Field Kit and the server with whom she syncs.
Question(s): Is it true to say that server is ALWAYS master of the data? That when FK “phones home,” she can pull any new or updated records from server, and/or write new records or updates to server, but never delete any records from the server? That, if FK were to lose her mind, any or all of her records, the worst she can do is waste some bandwidth by updating herself with another copy of all records, but there’s no way she can mess up the master database?
This has been my assumption-set, and it’s why i did use Field Kit for some time back in the v1.x server days, even though i did have some trouble with loss and/or corruption of data on the FK; rightly or wrongly, i never worried about messing up the mothership’s database -which problem i never had, fortunately.
Now if that is the case w/ these pre-production versions you are releasing these days, @jgaehring , then i’m inclined to want to get FK on my mobile, talking to my (Farmier-hosted) production instance of farmOS ASAP, because this promises to make for some significant improvements in workflows of our field workers, and the sooner we can understand and test the capabilities that FK can bring to our ops, the better. Am i wrong to be thinking this way about it?
This is basically correct. Field Kit won’t be able to do anything irreversible to the server’s database. Especially since farmOS v2 stores all revision data, the worst that could happen is you would need to go in and restore a log or asset to a previous revision.
The greatest risk, however, is that you record a bunch of logs but don’t/can’t sync them, then something breaks and that data never reaches the farmOS server in the first place. Particularly while I’m not enforcing schema changes with db migrations, there could be no way of fixing an issue like that w/o totally wiping the local data before it gets sent, other than manually entering it into farmOS. Now, I think even that possibility is extremely unlikely at this point, but it’s not 0, so I wouldn’t chance it. Of course, if you don’t have data in FK you care if you lose, then I’d say go ahead and experiment. But that’s a determination for users to make, and I just want to be clear what there’s no guarantee that data will be preserved.
Thanks for asking these questions, btw, helps me get this stuff out in the open that I otherwise just take for granted.
Right, i forgot: given availability of this rollback provision:
Considering this caveat, it’s a risk i’m willing to take w/in scope of the testing i’d like to do. Honestly, @jgaehring : do you really think even your most stable code will ever be able to guarantee a 0% chance of such data loss ever happening? There is no app i have ever had on my phone in which i would place such trust; even core apps like the Contacts database etc., i’ve never trusted completely enough that i don’t have data stored both to phone AND to either SIM card or cloud (or both!).
Seems to me the only way that we’ll ever have a solid Field Kit in production is via a fair number of users out the the field banging on it to root out the bugs that will inevitably appear in some configurations or other, acting out every UseCase you aim to support, along w/ some others that probably never occurred to you -am i right? If so, then let’s have at it!
Nope! But I guess the other half of the equation is just setting the expectation that there is little to be done if data gets lost in such an instance. I also can’t commit myself to helping anyone recover any lost data, since I’m trying to get this done sooner rather than later, which is the same reason I don’t want to get bogged down writing data migrations in the first place.
Happy to have some guinea pigs, so long as you know the score!
I totally understand and agree with your priority on getting the app done, & damn the torpedos. Again: if there be any users here with the expectation of data migration tools for this sort of mobile app, i have to wonder what gave rise to such expectation, since that is certainly not a norm in the mobile app dev space.
Anyway: this is about farming, after all, not banking or crypto, so… We’re all guinea pigs here, right?
Hello @jgaehring ,
I tried farmOS Field Kit and login to my farm os 2.0 at https://chienvu.farmos.net/. But still get error CORS. How can i do?
If you have a Farmier account, I believe you still need to enable Field Kit from farmOS first, is that right @mstenta?
That’s correct, but @henry there are no Field Modules available yet, so it would only be useful if you are experimenting with Field Module development yourself - in which case you would be better off setting up both a local farmOS development environment and a local Field Kit development environment.
Thank you @jgaehring @mstenta i will try setup it to local development. by the way let me ask how can i enable Field module in local development mode? is it automatically turned on?
Thank you again!
I’m still just hammering out the documentation and tooling for setting up the dev environment, but will make sure to post here when it’s available. Over on in the Matrix room we’re also talking about doing a little walk-through of the process next Thu, Feb 9, either before, during or just after the regular development call.
Within farmOS there is a farm_fieldkit
module that adds an OAuth2 consumer for Field Kit to connect to. This can be enabled either via the command line drush en farm_fieldkit
or by going to /farm/settings/modules
and enabling it via the UI.
I’ve been overdue once again for a substantive update, since I’ve fallen behind again on the timeline I posted in my initial update.
Work on alpha.9 and the Observations module is moving forward, it’s just taken far longer than anticipated. That said, I think as of yesterday the most challenging bits are complete, relating to how images and other files are synced between the remote farmOS server and cached in the local Field Kit database. Just now I had the pleasure of closing a couple pesky and truly ancient issues in the queue over on GitHub. As I mentioned in the topic on Fetching images, I’m tempted to merge this into main
for further testing, but for now I’ve just started a draft pull request.
Otherwise all that’s left is to update the UI for taking photos and notes on observation logs.
I’ll need to redirect my attention for the next week or so, as some other unrelated work has been postponed for too long as it is, but hope to have alpha.9 and Observations ready another week after that. Here’s my updated timeline:
Tag | Deliverables | Est. Release Date |
---|---|---|
alpha.7 | Stable API | Mar 24, 2022 |
alpha.8 | Tasks Field Module | Jan 4, 2023 |
alpha.9 | Observations Field Module | Mar 10, 2023 |
beta.1 | Stable UX & API Docs | Mar 20, 2023 |
Thanks for sharing
Hi @jgaehring and @walt,
I am happy to test it as well —I have no critical data in FarmOS quite yet and want to be a heavier contributor soon.
I think Field Kit (as well as @Symbioquine 's Assest Link) would be safer in instances where there is a solo user/tester for the instance (no timeline issues / synchro for data as being tested), which is my case for now
Can I help testing it? Thank you
Needless to say, i am as interested as ever (tho it’s been years already since last time) in testing this as soon as it comes avail.
I will also be so interested in bleeding edge testing. As you know @jgaehring from our discussions last year, I’m about to start my field measurement season and will happily use this. I don’t want to do FarmOS on a Raspberry Pi in a backpack again this year if I can help it.