@plypy, great presentation! Your English was very easy to understand and your presentation very easy to follow. Well done!
I would encourage you, working with @elliott, to identify the absolute bare minimum functionality needed to replace the existing OpenMRS ID and focus on getting that done and deployed before adding any additional functionality. For example, get ldapjs and current data provided by LDAP + MySQL working in MongoDB and replace OpenMRS ID with this before you begin working on any new API functionality. If you reach the end of GSoC with your project 99.9% done and not yet deployed, there is a chance it will never make it to production. Ideally, you would spend the end of the summer working on enhancements to code that you had already deployed.
Some unrelated questions…
How will clients of the API authenticate to it – i.e., who or what will have access to modify a user’s record?
If you have authority to make changes to the user’s entry, will you be on the honor code – i.e., clients are expected to only make changes to their own settings, but could technically change anything? Or will there be some scoping of authority so, for example, Atlas could only make changes to properties within extras.atlas?
Do you have thoughts on how you would control the namespace? For example, what if two different projects want to use extras.foobar.*?
Nice work! Looking forward to hearing more as GSoC progresses!
I agree not to worry about API things just yet. Still ahead on our roadmap is rolling out the new data model, ensuring backwards-compatibility with LDAP and migrating data from LDAP to Mongo. It’s important we get these things done ASAP so that we can get something out the door, and we can focus on the API next!
(Great presentation, as well! English was not a problem )
This is why I suggest wholeheartedly that we only support OAuth 2, which is already coded in the ID Dashboard OAuth Module. This means a couple things:
OpenMRS ID Admins control access to the API. Only sources we trust can authenticate and read/write ID data. We control what applications get client credentials required to use the API.
Authentication will be exclusively carried out via authorization tokens that are granted by the Dashboard. A token can be granted only with access to specific areas, so there’s no need for the honor system. Clients can only change their own settings, unless they ask for access to other data and the user approves of this access.