search

OpenNTI / nti.app.products.courseware_scorm

Other
0 stars 0 forks source link

Allow for the persistent configuration of IScormCloudClients or similar #79

Open cutz opened 3 years ago

cutz commented 3 years ago

Currently ScormCloudClient's get registered non-persistently via zcml. I'm working on a path that would allow internal operations groups and clients to instead do this persistently in their site. This obviates the need for an environment restart, allows ops more control, and gets us closer to clients being able to bring their own client. I'm not super familiar with this project so I thought I would outline what I believe needs to happen here.

1) Provide a persistent implementation of ISCORMCloudClient. This is likely a trivial subclass of the existing SCORMCloudClient and Persistent. There is a level of indirection in the current implementation where we assign an IScormCloudService to the cloud instance attribute. Care will need to be taken to make sure we don't persistently store that. 2) Provide nti.externalization support for ISCORMCloudClient so that the persistent implementations can be created from external sources (via internalization). This will include adding the fields app_id, secret, name, service_url to the ISCORMCloudClient interface.

Typically I would separate the credentials from the client itself, using adaptation to move between the two. In this case only the credentials would be persistent and the client would not. However given backwards compatibility concerns with the current code it's probably simpler to just make the client persistent and have it encapsulate the credentials on itself. That leaves all current use of component.getUtility(ISCORMCloudClient) unchanged. Is it worth a bigger change set to separate the two?

3) Establish permissioning for the persistent implementations. The details setup by the internal operations group would only be internally visible. Other clients created by site-admins (end users) could be managed by other admins. My intent is to use zope.security framework to grant appropriate roles, the appropriate permissions persistently on these objects. Are there suggested hooks for doing this?

Portions occurring elsewhere:

4) Facilitate the creation of these persistent ISCORMCloudClients in a site's default folder. i.e. POSTing the object to /dataserver2/++etc++hostsites/theclientsite/++etc++site/default. This is just creating a persistent object in a Folder. I'm thinking we likely have a generic view for this already? I'll need to work out permissioning here.

5) Provide for registering/unregistering these objects as utilities with the appropriate interface dynamically. Looking at zope.app.component for inspiration here. I think this is straightforward and likely generic.

cutz commented 3 years ago

@jzuech3 you're probably most familiar with this code. Gotchas to be aware of particularly with steps 1, 2, and 3?