IRC logs for #farmOS, 2018-08-23 (GMT)

2018-08-22
2018-08-24
TimeNickMessage
[22:29:31]* todrobbins[m] has quit (*.net *.split)
[22:29:32]* paul121[m] has quit (*.net *.split)
[22:29:33]* stanton[m] has quit (*.net *.split)
[22:36:41]* paul121[m] has joined #farmos
[22:36:50]* todrobbins[m] has joined #farmos
[22:36:59]* stanton[m] has joined #farmos
[12:15:35]<jgaehring[m]>mstenta[m]: The process for uploading files to the API (via restws_file) should be pretty much the same, regardless the file type, right?
[12:16:31]<mstenta[m]>jgaehring[m]: Yes as far as I know
[12:17:10]<mstenta[m]>The one thing you may need to change is the MIME type
[12:17:26]<jgaehring[m]>right
[12:17:29]<mstenta[m]>Have you tested it and run into an issue?
[12:17:32]<jgaehring[m]>that was my next question
[12:17:37]<jgaehring[m]>that's good news
[12:17:45]<mstenta[m]>The format just needs to be: "data:image/jpeg;base64,[BASE64_CONTENT]",
[12:18:01]<mstenta[m]>And you would replace "image/jpeg" with whatever mime type the file is
[12:18:02]<mstenta[m]>Oh...
[12:18:12]<mstenta[m]>But...
[12:18:16]<jgaehring[m]>i think i found our silver bullet for sending files from the client side: https://developer.mozilla.org/en-US/docs/Web/API/FileReader/readAsDataURL
[12:18:20]<mstenta[m]>farmOS itself limits the allowed file types
[12:18:36]<mstenta[m]>the image field only accepts jpg, jpeg, gif, and png i believe
[12:19:21]<mstenta[m]>oh wow - yea that looks like it does exactly what we need!
[12:19:39]<jgaehring[m]>that `readAsDataURL()` method formats it perfectly, and it comes free with the FileReader API, which is supported by Cordova and browsers >= IE10
[12:19:41]<mstenta[m]>it looks like it does both steps for you (1. get mime type, 2. get base64 encoding)
[12:19:49]<mstenta[m]>and just spits out the exact string that farmOS expects
[12:19:51]<jgaehring[m]>exactly!
[12:19:57]<mstenta[m]>beautiful!
[12:20:45]<jgaehring[m]>i forked MDN's jsfiddle example of its usage so it would just print the data url raw: https://jsfiddle.net/k52y6gps/
[12:22:11]<mstenta[m]>So what kind of a function is that? Not native JS right? JS can't read files, can it? (Unless they are public URLs)
[12:22:14]<jgaehring[m]>think i can just wrap up that in a function and let the logFactory call it when it comes time to package up logs for posting to the server
[12:22:36]<jgaehring[m]>it's a browser API
[12:23:38]<jgaehring[m]>but it's what Cordova uses too
[12:24:31]<jgaehring[m]>the browser support could be a smidge better, but IE10 ain't bad, and for now should be no problem whatsoever
[12:26:59]<mstenta[m]>ok cool
[12:32:17]<mstenta[m]>PS I was talking with donblair yesterday about the offline/native app work you're doing and he was excited about the approach
[12:32:21]<mstenta[m]>He's in Boston
[12:32:32]<mstenta[m]>We should all get together sometime :-)
[12:48:41]<jgaehring[m]>oh yea, that'd be great, loved talking with him when we were up at GOAT
[12:56:33]<jgaehring[m]>@donblair I'm curious to know if there was anything in particular that got your interest about the farmOS client (if this ping makes it through to you)
[13:00:05]<mstenta[m]>We were talking about the idea of having standalone scripts like that that could live on your desktop
[13:04:16]<jgaehring[m]>oh yea, maybe with Electron
[13:04:42]<jgaehring[m]>or do you mean like a full desktop GUI (that's what Electron could provide), or just like a desktop widget?
[13:09:46]<mstenta[m]>Oh cool
[13:10:09]<mstenta[m]>Nah we were just talking generally about the usefulness of an approach that can be used in different contexts
[13:11:05]<jgaehring[m]>oh yea, cool
[13:15:16]<jgaehring[m]>i should take the notes I have right now in my fork of the farmOS.org docs, and clean them up for anyone who's interested in the technical aspects
[13:16:39]<jgaehring[m]>and a non-technical write-up would be nice too
[14:25:05]<donblair[m]>jgaehring[m]: hallo! thanks for the rapid reply --
[14:25:46]<jgaehring[m]>howdy!
[14:25:46]<farmBOT>que tal
[14:26:31]<donblair[m]>Mike and I were chatting about logging and graphing sensor data in FarmOS --
[14:26:53]<jgaehring[m]>oh yea, cool
[14:28:58]<donblair[m]>one thought was: I could work on a way of graphing sensor data using html + javascript (using D3, say), with data being stored [somehow], and that at some point the relevant html+js could be brought into FarmOS as a module
[14:30:16]<donblair[m]>and when he told me about the 'webapp' approach you're taking, it seemed like a really cool way of allowing sensor datalogging to happen: locally with a smartphone; locally on a raspberry pi; and then in the cloud as a farmos module
[14:30:54]<donblair[m]>the other thing we talked about was the possibility of leveraging the 'dat' protocol, as the Beaker Browser folks are doing
[14:30:55]<jgaehring[m]>awesome, yea, i like it!
[14:31:21]<jgaehring[m]>OHHHH DAT, HELL YEA!
[14:31:44]<donblair[m]>oooooooooooh really, you're hip to dat?! shweet!
[14:32:02]<jgaehring[m]>yea, really want to play more with it
[14:33:00]<donblair[m]>our friend RJ has been working on a native Android app that speaks dat -- it's being prototyped as a way of allowing p2p android sharing of databases in an intermittent-connectivity context
[14:33:03]<jgaehring[m]>so as far as displaying the data, that should definitely jive with what I'm doing
[14:33:26]<donblair[m]>meanwhile, it seems that the dat folks have come up with a prototype 'multiwriter' protocol, that allows more than one person to write to the same dat archive ...
[14:33:30]<donblair[m]>oh super cool!
[14:34:29]<jgaehring[m]>oh that's really cool, i've only really played around with Beaker, but i've been meaning to read the Dat white paper for a lil while
[14:34:29]<donblair[m]>so maybe a path forward would be: i can play with graphing data in simple ways, and then sort of be agnostic about where the data is coming from -- it could be via a (future) FarmOS sensor data API, or via local storage in the browser, or via a dat archive ...
[14:34:46]<donblair[m]>coool!
[14:34:58]<jgaehring[m]>so, basic run down of the client framework i'm working on...
[14:35:27]<donblair[m]>yes, please: eager for the rundown!
[14:36:03]<jgaehring[m]>there are 3 major aspects to it, at least, in theory (trying to get the practice caught up to the theory, but for now)...
[14:37:44]<jgaehring[m]>1) there are modules, which are top level components for rendering a portion of farmOS data... they more or less correspond to a regular farmos module, like plantings or observations
[14:39:09]<jgaehring[m]>2) there are drivers, and those are implementation specific interfaces, which tell the app how to work with a specific hardware or browser API, depending on the context
[14:39:10]<donblair[m]>got it ...
[14:39:50]<jgaehring[m]>3) and then there's the core, which just plugs those things together and provides a very basic app shell, with some basic data like user and host info, settings, etc
[14:42:39]<donblair[m]>ah, coool
[14:43:03]<jgaehring[m]>so right now I'm focused on the native (iOS & Android, via Cordova) implementation, but to get another implementation started, we'd just need to provide drivers, then whatever existing modules we've already got written, should provide a UI, ready to go
[14:44:54]<donblair[m]>very very cool!
[14:44:54]<jgaehring[m]>likewise if you want to do provide a new UI, like for graphing data, you should only have to write it once for your browser, and then it should automatically port to the mobile version as well
[14:45:49]<donblair[m]>that's so slick
[14:46:06]<jgaehring[m]>haha, well, we'll see
[14:47:14]<jgaehring[m]>most of that stuff is very theoretical right now, still very focused on the native drivers right now, so it's hard to test out other implementations for now, but that's the dream
[14:47:14]<donblair[m]>and my understanding from chatting with Mike is that there isn't currently an API for e.g. pulling the 'last N readings' from stored sensor data on FarmOS (in what I suppose is a 'sensor module' or equiv)
[14:48:00]<donblair[m]>gotcha -- so at this point you're mostly making sure that you can get basic functionality working on android and iOS?
[14:48:17]<donblair[m]>like e.g. pulling GPS coord, camera, etc?
[14:48:47]<jgaehring[m]>right, working on the camera as we speak, actually
[14:50:35]<jgaehring[m]>i'm keeping some running notes here https://github.com/jgaehring/farmOS.org/blob/new-arch/docs/development/c...
[14:50:50]<donblair[m]>ah, fantastic
[14:51:36]<jgaehring[m]>though i warn you it's a largely unfiltered brain dump, parental discretion advised
[14:51:42]<donblair[m]>for what it's worth, Greg Austic at Our-Sci has been working on developing mobile web-apps -- I'm not sure the approach is the same, but I think it might be, at least at a high level -- this might be the relevant repo? https://gitlab.com/our-sci/android
[14:52:15]<donblair[m]>haha that's the right way to approach documentation at first mid-process!
[14:54:55]<donblair[m]>so it sounds like two relevant paths for what i'm doing rn might be: jam on making a prototype html+js sensor graphing UI (with whatever data storage architecture, for now), and meanwhile also see what an MVP dat-based approach might be (for kicks)
[14:55:45]<donblair[m]>fwiw, this is the android-based dat-enabled browser (android equiv of Beaker) that RJ has been jamming on, in case it's of interest: https://github.com/bunsenbrowser/bunsen
[14:56:19]<jgaehring[m]>oh awesome, i gotta check all this stuff out
[14:56:42]<jgaehring[m]>really want to dig into what Greg's working on there too
[14:56:50]<jgaehring[m]>but yea, that sounds like a good approach
[14:57:19]<donblair[m]>meanwhile maybe i should also see if i can follow your dev path in a sort of minimalist way and get some web app sensor graphing prototype working on e.g. android via cordova
[14:58:12]<donblair[m]>i'm playing with capturing sensor data via the USB port on android -- does cordova allow (properly wrapped web apps) access to USB?
[14:58:22]<jgaehring[m]>the goal is to have the UI handling a very plain, JSON-like representation of any and all data, no matter the source, so if you're mocking some data in D3 for the time being, it should be simple enough to convert that into a module for the client
[14:58:22]<donblair[m]>(this may be what Greg is already doing)
[14:58:42]<donblair[m]>oh fantastic, that sounds perfect
[14:59:26]<donblair[m]>i've gotta run now, but it'd be great to set up a time to chat to compare notes
[15:00:19]<jgaehring[m]>yea, we should, i think there are ways you could probably even start writing that stuff as a client module, with minimal changes to the HTTP driver as written now
[15:00:30]<jgaehring[m]>but let's definitely pick that up at a later date
[15:00:30]<donblair[m]>i'm basically hoping to make some simple, end-to-end sensor --> farmOS graphing system prototype -- the sensor prototype is nearly there
[15:00:38]<donblair[m]>oh that sounds great
[15:01:26]<donblair[m]>yeah, it'd be great to approach this in a way that has maximum useful overlap with what you're already jamming on ... i'll try to better grok what you've done so far
[15:01:45]<jgaehring[m]>gaehj457@gmail.com if you want to schedule something
[15:02:08]<jgaehring[m]>yea, no, i'd love to plug you in better to what I'm doing
[15:02:20]<donblair[m]>awesome! will fire off an email now -- thanks!
[15:02:33]<jgaehring[m]>cool, talk to you soon!
[15:02:52]<donblair[m]>yes, and it'd be awesome to connect with the dat folks too -- so much exciting energy there, and maybe some interesting directions for farmOS
[15:03:00]<donblair[m]>shweet! thanks for the intro, Mike