Hi Sandy, > I am reaching out to get a sense of how extensively PDF certificates > are used by other Open edX instances
As disccussed in Slack, Stanford uses these extensively. > and how much of a burden it would be for those instances to move to > web certificates. Too much. We have no plans to do so. Besides the effort involved, we prefer the UX and product workflow of PDF certs. > edX.org no longer supports PDF certificates Stanford has maintained our fork of the codebase since late 2014 [1]. Before we forked, we were the active maintainers of the core repository; we used to have commit access and our developers have authored 78/136 of the commits to-date [6]. Since forking, we have continued to improve the codebase, including the introduction of a YAML-based templating system which significantly increases speed and ease of certificate design and development [2]. > as we move away from using RabbitMQ, we are also moving away from > supporting PDF certs because they are integrated directly with > RabbitMQ This isn't quite right; certs integrate via XQueue, not RabbitMQ [3]. > they are not managed by Celery like other asynchronous tasks. There's some truth here. The certificate "agent" [3] is a supervisor-managed service that polls an XQueue endpoint and pops/processes jobs from there. We've previously expressed interest in decoupling certs/xqueue for varying reasons, namely that we have a few deployments that otherwise don't need XQueue and it would be nice to remove that dependency from the infrastructure. I did a proof-of-concept of this waaay back at the 2015 OpenEdX Conference Hackathon, but never had the time/motivation to make it production-ready [4][5]. We'd be interested in finding a path forward in revisiting this. That said, unless edX has plans to deprecate XQueue (do you?), this seems to be a less pressing concern. > We are looking at the possibility of deprecating PDF certificates as > part of the next Open edX release and possibly even deleting the code > entirely. We would not like to see this happen and hope to find a path forward for preserving this functionality. We'd like to explore options for assuming stewardship of this codebase, so let us know how we can help. Thanks for reaching out and hope to discuss further, Steven at Stanford [1] https://github.com/Stanford-Online/openedx-certificates [2] https://github.com/Stanford-Online/openedx-certificates/blob/master/cert-data.yml [3] https://github.com/Stanford-Online/openedx-certificates/blob/master/certificate_agent.py#L26-L32 [4] https://github.com/stvstnfrd/edx-certificates/pull/1 [5] https://github.com/stvstnfrd/edx-platform/pull/12 [6] https://github.com/edx/edx-certificates/commits/master -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/b8005fa2-e5e6-4053-8709-791b34fbf8ff%40googlegroups.com.
