Discussion about the state and a near-term plan

[ebihara99999]

This is taken from a part of the conversations here.

splitting the external providers into its own gem should probably happen sooner rather than later.
@Ch4s3 perhaps we should set a time for discussion on the state of Sorcery and our near-term plans for it?

[ebihara99999]

Again, the following is my opinion for now.

At first, devise-like multi scopes’ login, which is not by STI. Everytime I talk about Sorcery with some people, we feel necessity of the login feature to use with more flexibility. STI is only useful for limited usages.
Secondly, I recommend API mode support as the JWT PR implements. Sorcery will become more attractive to rails developers if Sorcery supports the api mode now that developers will make a SPA application.
The last is, to prepare full helpers needed to develop a rails app like request and system spec helpers. Now controller specs are deprecated and recommend using system specs instead of feature specs.

[Ch4s3]

@ebihara99999 I'm on board, but don't have a lot of time at the moment. If other folks get started, I'll happily jump in.

[ebihara99999]

@Ch4s3 Thank you! I will start implementing the three features in my repo and mention to you then.

[joshbuker]

@ebihara99999 @Ch4s3 @mladenilic @z1lk, and anyone else interested in helping maintain Sorcery (#204):

We should set aside some time to discuss short and long term plans for Sorcery. Does Sorcery still make sense? What role does/should it fulfill in the ruby ecosystem? How much code should be delegated (e.g. Omniauth and OAuth support)? etc.

[z1lk]

Hey, thanks for including me. At this point I have not begun looking at issues (as mentioned in #204) and thus haven't explored how Sorcery is structured internally. I'll see if I can work on some issues soon and get a sense of the state of things.

[joshbuker]

This will be continued by #248, closing.