Separate adapters from the main repository

[tstarck]

In package.json, Debian package or both?

[amv]

The sqlite3 dependency with all of it's native code actually seems to make the system a lot harder to install (although the sqlite library itself is pretty lean).

It would be cool to create for example a default file system based adapter which had no extra dependencies and then publish both mysql and sqlite as optional add-ons.

[amv]

I wrote a suggestion for the file system adapter as #67.

[jarnoharno]

mem-adapter, anyone?

SQLite adapter kind of tries to be the local file system adapter, so implementing another one just to get rid of a dependency might be an overkill...

There is also the possibility of just not providing any adapters out of the box. The user would obviously then be forced to install one of the optional adapter components from npm (which is not that big of an issue IMO).

[jarnoharno]

Make note that getting rid of these dependencies would also simplify the development and installation of custom controllers which need component.js and multiserver stuff from gearsloth package but don't generally need the said mysql and sqlite packages that the gearsloth package depends on.

[amv]

@jlep I kind of fell in love with the fs adapter idea and started developing it to become the default storage as you found out a way to do it nicely without adding any dependencies. The benefits of it IMO are:

• It allows spinning components as different processes for blackbox tests (unlike mem).
• It is persistent in a way which has very known failure modes and recovery tools.
• The storage state can be viewed with simple command line tools like cd, ls and find, which helps communicate how the system works.
• It could actually be used in production after the db specific ejector logic is implemented.

The mem-adapter is a great example by the way, and I think it should be linked to from the documentation as a reference for future adapter developers.

[amv]

The fs-adapter branch now contains a way to run some integration and system tests with any adapter that implements the new adapter interface (the GEARSLOTH_TEST_ADAPTER env variable).

I'm thinking of packaging also the fs-adapter as it's own repository and npm module, maybe adding it only to the dev dependencies.

does anyone have any thoughts on wether this is a good idea or if the fs adapter should just come bundled along with the software itself?

what are the benefits and drawbacks?

[amv]

I renamed this ticket and placed it to be developed later. We can have all of the adapters in the repo for now, but in clear places so that they can be easily separated later.

I think it would be a good idea to have the software depend on the FS adapter but still have the FS adapter in a separate repo later on.