Indy catalyst server repository re-org

[ianco]

Re-org the credential registry server code

• starter kit vs shared code
• Package these as re-usable python modules under: indy-catalyst/credential-registry/server
• init.sh script to create a “copy” of a starter kit?

[swcurran]

@nrempel - What is the status of this update? As I recall, we had a follow up meeting on this and decided not to do much with this - a few tweaks but basically not change from the starter kit model. Is there anything to do on this after that decision?

[nrempel]

@swcurran I think at the least there is a good amount of cleanup that we can do to make it more approachable and useable. We can also ditch a lot of cruft that has accumulated over time.

As far as the model goes, I think we never really landed on anything concrete. Emiliano and I plan on discussing the model again once we get to this task.

[swcurran]

@nrempel - is there a document that outlines what's going to happen? I'd like to suggest an alternate approach to this task to reduce the time to completion of something useful. Can you document how a new user would standup a Credential Registry and a Credential Issuer as it stands today so we can use that for anyone that wants to get started now. In doing that, you can identify the specific things that we can do to simplify the process - basically, to make the process easier. Then, we can prioritize the list of changes to be made.

In the meantime, we could use the documentation as the basis for pushing Indy Catalyst and the Issuer Agent repos to Hyperledger and people could get started.

@ianco @esune @jljordan42 - thoughts on this approach?

Reasonable?

[esune]

The "quickstart" document seems like a good idea to me. I don't think it will/would look different after the refactoring/cleanup as the purpose of this process is just to rearrange the repository and the code in a way that is potentially more manageable. Most of the documentation will be around where to get each component and how they connect, the current documentation and manage scripts are otherwise relatively easy to follow.

I do not think we wrote a document about the steps we want to take, if I remember correctly it was something among these lines (but @nrempel and @ianco can chime in as well and correct me if I am wrong):

• rearrange directory structure in repository to make it cleaner and easier to navigate
• refactor API modules - if possible - so that they will be completely independent and installable/pluggable. If this is not possible, ensure configuration settings to enable/disable functionality are well documented and as few as possible.
• refactor APIs to return data in a "credential-like" fashion, which means: no internal django ORM IDs reported, different data structures. This would/could be API v3 (our path and request headers now support API versioning).

[ianco]

Yes that is basically what we discussed.

I think the third bullet (refactor the API's) is the most important. There are some performance issues right now caused by the Django ORM, and overall I find the API's confusing (the terminology as well as the use of internal database ID's)

[seanadipose]

@ianco @esune @jljordan42 @swcurran I can take the first stab at doing a quick start guide that goes through start to finish on setting it up since I just went through getting my dev environment going this week with fresh eyes this week. I'll identify the challenges I had share them as well.

[swcurran]

Awesome! Go for it.

[nrempel]

Thanks @esune that about covers it. I haven’t had time to dig into this with the recent work on iiwbook and elsewhere.

@seanadipose and I are in contact and I can touch base and pick up when I get back.

Thanks!