file and dependency discussion

[amark]

Excellent documentation at https://github.com/sjones6/gun-flint/blob/master/docs/INTEGRATION_TESTING.MD !

It made me realize I should chat with you about two things:

1. For a while now, I've generalized/standardized file option to be reusable by anybody/everybody else (not just the default adapter!). There is absolutely no need to use it, in fact it probably is smarter for every adapter to have its own option names that a user is forced to read / understand the documentation on the tradeoffs involved (that while everything is plug-in-play, they should still think carefully/critically about their decisions).

So then how do you turn off the default file adapter? By requiring gun/gun and manually including whatever other default adapters you do or don't want.

^That now frees up file option for other people to use (if they want to), and not having to set it to false. In fact, setting file to false does NOT disable the default adapter anymore - I think I had mentioned this to people back at the end of v0.7.9 / v0.8.0 but I apologize if I didn't communicate this more clearly. So just wanted to remind you of this again (or for the first time?) since I saw in the documentation. (Everything else was fantastic though!)

2. NPM dependency (or /not depending/) on GUN is still weird. This is my fault, not yours.

I don't know if I'm just being stupid or not though, but it truly stumped me. Even though this has been a cliche problem since jQuery days... even with all the fantastic tooling of NPM and what not, there doesn't seem to be a simple answer to this, even though it seems like it should be easy? Or am I just infinitely confused / missing something obvious?

To me, it is absolutely clear/obvious, that modules/adapters SHOULD NOT be locked down to a specific version of gun (other than lets say, major breaking versions of gun with breaking API differences). Why? Because then it would be effectively impossible for an end user to use more than 2 modules/adapters together, because they would depend upon slightly different gun versions! Worse, your node_modules folder would bloat with like 7+ different versions of gun that each different adapter/module specified.

People in the past said "oh pass the module the gun instance" which sounds smart, but it actually doesn't solve ^ the dependency/bloat problem. It effectively has the same result as what we've temporarily done of "just don't list gun as a dependency", because whether you are explicitly passing it a gun or it is implicitly using whatever gun exists in your project... both are either gonna "just work" or crash hard due to some major API breaking changes (which thankfully, those are almost all gone now). Crashing hard is the result you want (rather than silently failing) so at least people know they are incompatible at a major API level.

However, of course, it would be ideal to avoid it ever crashing at all, because some how the NPM dependencies all automatically worked themselves out and used the SAME gun version (and therefore, also then the same require and same class / constructor). But IDK how to make that happen? Greedy note: The more projects that I can get to list gun as a dependency, the better my NPM installs/traction/downloads are - versus, right now, asking adapters/modules to NOT explicitly depend upon gun :P means it is harder to have easily findable / trackable stats. Anyways, this isn't important short term, but would be nice to figure out long term, since it is kinda odd.

</end ramble>

Feel free to close this, just wanted to catch you up / see if you had any thoughts.

[amark]

oh, and related to the gitter discussion on connect/disconnect. I'm gonna use hi and bye events in my default drivers, and hopefully other drivers will use them too. More importantly: I'm gonna build an adapter on top of that that tries to make those events as useful as possible, but it will probably turn out ugly :( so maybe we can see in the future if flint could evolve to handle/standardize it as well into something more beautiful! Of course no rush on that, but just wanted to let you know I'm open to that even though I'm implementing something already - ideally the only thing we'd have to agree upon is the event/adapter/hook names I've already biased of hi and bye. :P

bye! :P

[sjones6]

@amark :

1.) Yep, I think I've got this down now. It took a minute. I've been trying to scrub my documentation and code of references to that.

I've started up a module loading package but I haven't really gotten so far yet. I'll let you know if something comes of it.

2.) I mentioned this to you on Gitter ... but here's what I think we need to communicate:

You should treat your Gun constructor like you would treat any DB dependency. There should only be one in your system unless you're intentionally communicating with multiple DBs, in which case they should be clearly distinguished.

The corollary that makes this difficult is that there is no guarantee from NPM that require('gun') will always return a reference to the same Gun constructor. Herein lies the problem that needs solved.

Tuning my brain to think about the constructor like a DB has helped me, however.

3.) hi, bye ... and err I think we'll need as well. We can definitely standardize into flint if needed ... but I'm not totally sure how these fit in adapter-land so you'll need to spell that out.

This definitely makes sense for peers, though, and handling the ws events.