android-fhir
android-fhir copied to clipboard
Loading context worker using the Knowledge manager
Is your feature request related to a problem? Please describe.
- Adding the ability to install multiple IGs into the worker context based on comment 1 here
we could try to implement the IWorkerContext using knowledge manager, and essentially for knowledge manager to provide a worker context to the SDC library to use. This way, as an Android developer, your interation with npm packages should all go through knowledge manager.
Would you like to work on the issue? @joiskash and @nsabale7 will be looking into this
@jingtang10 @joiskash @owais-vd check this out
I suppose my objection to the above design is how do the applciations maintain the npm packages? do we expect app to store and manage the npm packages and call the knowledge manager API with them?
i think the npm packages should be managed by the knowledge manager - and that's the knowledge manager's job really. so that the api should be adapted so that the application only needs to pass the ids of the npm packages to the knowledge manager for it to generate worker context containing multiple npm packages.
@joiskash, did you manage to discuss this at today's the wg2 call? an alternative approach would be for this information not to be provided by the application, but for the sdc library to have a direct dependency on the knowledge manager which will return a worker context containing all the npm packages stored locally. this means that the application doesn't have a say on which npm packages to use, but the km simply creates a worker context that uses all available npm packages.
Yes I did discuss. The conclusion was that it is safe to assume that IGs will not have structure map with conflicts. But on the other side, if apps are designed to serve dynamic content based on Patient and usecase, then it might be better to have a way to load contexts with specific IGs. I think in either way, keeping the knowledge manager responsible of handling and managing the NPM packages makes sense to me. @dubdabasoduba what do you think?
To summarise this morning's discussion at the developers call: I think we agreed due to the performance concerns on loading npm packages into worker contexts, it's best to give application the chance to frontload such operations. as a result i think having this as a separate util make sense, as opposed to letting the knowledge manager handle this at the point of extraction.