| [02:18:33] | * alexheiss[m] has quit (Ping timeout: 250 seconds) |
| [02:18:35] | * munjoma[m] has quit (Ping timeout: 250 seconds) |
| [02:18:59] | * stanton[m] has quit (Ping timeout: 250 seconds) |
| [02:19:36] | * alexheiss[m] has joined #farmos |
| [02:20:16] | * munjoma[m] has joined #farmos |
| [02:23:59] | * stanton[m] has joined #farmos |
| [04:51:04] | * stanton[m] has quit (Ping timeout: 250 seconds) |
| [04:51:56] | * alexheiss[m] has quit (Ping timeout: 250 seconds) |
| [05:02:23] | * alexheiss[m] has joined #farmos |
| [05:03:37] | * stanton[m] has joined #farmos |
| [08:33:45] | <jgaehring[m]> | yes, that's primarily what I have a mind to, in structuring the monorepo... i still need to play around with exactly how it works if import the npm packages from the monorepo into another repo, but it should be easy... or we could even include the farm_offline module in the monorepo too |
| [08:37:57] | <jgaehring[m]> | i think there's also some potential to reuse the http plugin for doing ajax, once that's made into its own package too, though i'm not 100% sure about that |
| [09:11:29] | <mstenta[m]> | awesome! |
| [09:11:46] | <mstenta[m]> | i love the idea of eventually including the same client UI in farmOS itself |
| [09:12:23] | <mstenta[m]> | and it's also neat if it can be used completely disconnected from either the native app OR the server (ie: running it as just a set of files on your desktop) |
| [09:12:56] | <mstenta[m]> | obviously not the priority right now... but it's exciting to think that we have that much flexibility, potentially. |
| [09:13:36] | <mstenta[m]> | (it also just serves as an interesting design approach in general - and something that could be generalized to other applications - like the sensor stuff donblair is working on) |
| [10:13:26] | <jgaehring[m]> | yea, i've been thinking about how it could be an embedded UI for sensors as well, that would really be awesome! |
| [10:18:05] | <jgaehring[m]> | i now have the data plugin running as its own package successfully too, and have the client running much more smoothly as a package, but got snagged when I realized I created an (unrelated) bug when I removed jQuery, had to switch my focus back to that... otherwise i'm pretty confident i could start experimenting very soon with using these packages in other contexts besides the native app |
| [11:12:30] | * mstenta has joined #farmos |
| [11:22:18] | * farmBOT has joined #farmos |
| [11:22:23] | <mstenta[m]> | aw you killed farmBOT again |
| [11:22:25] | <mstenta[m]> | :-( |
| [11:22:46] | <mstenta[m]> | does anyone here know of a good IRC bot for logging? |
| [11:23:12] | <mstenta[m]> | preferably something that makes the log visible via a web UI? |
| [11:23:29] | <mstenta[m]> | farmBOT: log pointer? |
| [11:23:29] | <farmBOT> | http://irc.farmos.org/bot/log/farmOS/2018-10-30#T29592 |
| [11:24:30] | <mstenta[m]> | I like the way this one works... but I'm curious about alternatives |
| [11:26:15] | <jgaehring[m]> | could it possibly be fixed to support unicode emoji's? would that be an easy fix? |
| [11:26:38] | <mstenta[m]> | maybe |
| [11:27:10] | <jgaehring[m]> | is it this? https://www.drupal.org/project/bot |
| [11:27:51] | <mstenta[m]> | Yup |
| [11:28:12] | <mstenta[m]> | No longer maintained... :-( |
| [11:28:39] | <mstenta[m]> | oh looks like there's an issue: https://www.drupal.org/project/bot/issues/1886646 |
| [11:29:05] | <mstenta[m]> | oh dang! "Converting the tables and database that run the bot to utf8 charset and utf8_general_ci collation should fix it." |
| [11:29:12] | <mstenta[m]> | is that all?? |
| [11:30:29] | <jgaehring[m]> | [fingers-crossed emoji] |
| [11:30:36] | <mstenta[m]> | Ah ok... a little more to it than that... but not much... |
| [11:30:45] | <mstenta[m]> | Well, I'll add that to my todo list ;-) |
| [11:30:49] | <mstenta[m]> | Haha |
| [11:31:05] | <jgaehring[m]> | haha, the very bottom of it i hope |
| [11:31:08] | <jgaehring[m]> | sorry again |
| [11:31:53] | <mstenta[m]> | I'm just impressed that you are so adept at emoji use |
| [11:33:55] | * mstenta has quit (Quit: Leaving) |
| [13:38:20] | * mstenta has joined #farmos |
| [15:55:45] | * mstenta has quit (Quit: Leaving) |
| [17:52:26] | <jgaehring[m]> | looking at it more, i'm wondering how badly do we want the farm_offline module to be its own repo, are there reasons for how it will interact with Drupal core? There would be [ways to do it](https://stackoverflow.com/questions/39194648/npm-install-package-from-gi...) if it was not a part of the monorepo, but they're hacky |
| [18:04:03] | <mstenta[m]> | In the long run, it might actually be nice if the farm_offline module (or whatever it is named) lives in farmOS itself, and simply loads the built client js (which could be included as a library in Drupal) |
| [18:04:52] | <mstenta[m]> | Would something like that work? |
| [18:05:44] | <mstenta[m]> | In that context, it would use localstorage instead of websql |
| [18:07:15] | <mstenta[m]> | And the Drupal module would be thin... Essentially just a container that handles integrating the app into Drupal |
| [18:07:27] | <jgaehring[m]> | another option that would simplify things would be to publish these as public npm packages |
| [18:08:31] | <jgaehring[m]> | then instead of working out how to pull things from github, which works well but has limitations, we could just pull the packages from npm, much more cleanly |
| [18:08:44] | <mstenta[m]> | Ok |
| [18:09:24] | <jgaehring[m]> | should still have the same options to install the built version or pull it directly from source for development purposes |
| [18:09:25] | <mstenta[m]> | Yea let's take a look at it together sometime soon via screen share |
| [18:09:33] | <jgaehring[m]> | cool |
| [18:09:57] | <mstenta[m]> | I can show you what I'm imagining in terms of pulling the library into Drupal |
| [18:10:13] | <jgaehring[m]> | ok, yea, that would be helpful |
| [18:10:16] | <mstenta[m]> | (and how that normally works in Drupal) |
| [18:10:51] | <mstenta[m]> | I can show you Openlayers as an example |
| [18:11:20] | <mstenta[m]> | (a separate project/library that gets pulled in during farmOS build process) |
| [18:11:53] | <mstenta[m]> | There will definitely be some things to think about... Ie with login/authentication |
| [18:12:45] | <mstenta[m]> | I think it will help to start with getting it to work on its own with local storage first (ie running it from desktop locally) |
| [18:13:05] | <jgaehring[m]> | not sure if i could get a working version up fast, but i could try to make a duplicate of the native repo that just has the native code and pulls its dependencies (client and plugins) entirely as separate npm packages, from outside the monorepo, to see if that works |
| [18:14:03] | <jgaehring[m]> | that's right weren't you experimenting with localstorage on something? trying to remember the gist... |
| [18:14:40] | <mstenta[m]> | Yea just remembering open/closed state of the help text |
| [18:14:44] | <mstenta[m]> | Simple |
| [18:15:41] | <jgaehring[m]> | oh right |
| [18:17:43] | <jgaehring[m]> | yea, i'm thinking we could either use localstorage or indexeddb, which is meant for larger datasets |
| [18:18:37] | <mstenta[m]> | Ok |
| [18:23:34] | <jgaehring[m]> | that's right, had to Google "localstorage vs indexeddb" but the main difference is that localstorage is synchronous, so it could potentially cause the UI to lag while retrieving logs from storage, if it got to be a sufficiently large number of them |
| [18:25:01] | <jgaehring[m]> | but either way, same concept, we just make a plugin for whichever persistence API we want to use, and add that to the client in lieu of the websql plugin |
| [18:26:02] | <mstenta[m]> | Cool |
| [18:28:23] | <jgaehring[m]> | i'm curious to see how JS libraries are added to Drupal, if you could show me with a screenshare |
| [18:29:49] | <mstenta[m]> | Can't right now, but maybe I can explain |
| [18:29:53] | <mstenta[m]> | (on my phone) |
| [18:30:53] | <mstenta[m]> | Basically farmOS gets "built" using a program called Drush |
| [18:31:24] | <jgaehring[m]> | oh at a later date, when we can do a hangout |
| [18:31:30] | <mstenta[m]> | (and in Drupal 8, Composer, which is the standard for PHP dependency management, similar to npm) |
| [18:32:08] | <jgaehring[m]> | sorry, didn't mean ask for a long explainer now, but if you care to do a flyby now, by all means |
| [18:32:12] | <jgaehring[m]> | :) |
| [18:32:36] | <mstenta[m]> | No prob |
| [18:33:29] | <mstenta[m]> | So that build process gets Drupal core, along with modules, themes, and other things like js libraries |
| [18:33:41] | <mstenta[m]> | And puts them in the right place in the codebase |
| [18:36:16] | <jgaehring[m]> | Where does it get the js libraries from, can it pull them over a network? |
| [18:36:36] | <mstenta[m]> | Yea, from anywhere - github, or just a URL |
| [18:36:59] | <mstenta[m]> | In the case of JS libraries, those go into sites/all/libraries |
| [18:37:06] | <mstenta[m]> | And then the Libraries module in Drupal handles loading them |
| [18:37:20] | <mstenta[m]> | So modules can just say "hey I need this library on this page" and it loads it |
| [18:37:27] | <mstenta[m]> | Ie: if you make a map, it loads Openlayers |
| [18:37:49] | <cycix[m]> | I see there was some stuff above about running FarmOS locally as a desktop type app. I'm not sure if something like this project has been considered as a potential solution: https://github.com/cztomczak/phpdesktop |
| [18:41:13] | <mstenta[m]> | <mstenta[m] "Ie: if you make a map, it loads "> cycix: interesting |
| [18:41:17] | <mstenta[m]> | Oops didn't mean to quote that |
| [18:46:19] | <jgaehring[m]> | Very interesting cycix[m], is that anything like electron? |
| [18:51:55] | <jgaehring[m]> | mstenta[m]: ok, so Drush can download the package into sites/all/libraries, from git, or a cdn, or anywhere... wondering if it has npm support to download from their repositories, but if not, a nice thing about npm is unpkg, which automatically makes any npm package available as a cdn for script tags https://unpkg.com/ |
| [19:03:57] | <cycix[m]> | I'm not sure I haven't used it either, but when I saw that above I thought about that mozilla prism program (I guess now discontinued) and that turned up in some searches. I thought it might be worth throwing out on the table. |
| [19:09:35] | <jgaehring[m]> | cycix[m]: yea, i'll have to check it out! we're playing around with the idea of ways we can extend the [client](https://farmos.org/development/client/) i'm working on to fit into other environments... right now it works with native, but we're toying with the idea of a Drupal module or even an embedded UI in a sensor |
| [19:52:10] | <mstenta[m]> | No Drush doesn't do npm as far as I know |
| [19:53:08] | <mstenta[m]> | With openlayers, for example, it just pulls the packaged release from GitHub, which has the built JS and CSS |
| [19:53:42] | <mstenta[m]> | So I wonder if we could provide something similar: a release that is just the JS and CSS |
| [19:54:26] | <mstenta[m]> | Basically what we are creating for PhoneGap Build... But with the localstorage driver instead of the native stuff |
| [19:57:12] | <mstenta[m]> | This is also worth considering, when farmOS moves to Drupal 8: https://medium.com/myplanet-musings/how-to-install-a-node-js-project-wit... |