To me, it seems that the best course of action to take on developing this product based off of the design goals from exercise 4 and the parameters laid out in the above morphological chart are as follows:
- It should be similar in use to a traditional search engine. Why reinvent the wheel? Eveyone is familiar with the interface and can use it effectively. Not everyone uses command line and that can prove to be problematic across systems. Mobile app interfaces are "too much" for a system like this and will detract from its streamlined nature
- It should use word tokenization. It is more reliable and easier to implement than traditional grammars, and is more deterministic than machine learning
- We should integrate with GitHub, provide cloud storage solutions, and allow for local servers to handle the data. The only reason I can safely say that all three can be implemented is because of the great flexibility of the Elasticsearch system.You can simply point it at a webaddress or a server location and it will store everything there in its own server. GitHub integration would also allow us to track multiple version of the same code. This can be leveraged through clever use of GitHub Apps
- For security, tiered permissions seem to be the best solution. Allowing users to some code and not other code can be handled through request management and encryption. Request encryption can be handled relatively efficiently by things like JWT (JSON Web Tokens) and HTTP encryption protocols, however, full code encryption would require time and computational power that isn't comparable to the benefit it would produce at the earlier stages of development. As for local-only storage; it seems to be great from a security front but totally impractical. Many individuals and companies trust cloud server systems and removing that functionality would be counter productive. Should a client require that kind of security, it can be provided on a case by case basis.