Please add CDN or Bundle external requirement in elyra

I got super slow jupyter lab startup due to Failed to connect to URL for component . Why not bundle these dependency inside elyra by submodule or something else ?

[I 2021-09-22 20:13:59.561 ServerApp] nbclassic | extension was successfully loaded.
[I 2021-09-22 20:13:59.561 ElyraApp] Config {'ServerApp': {'jpserver_extensions': <LazyConfigValue value={'jupyterlab': True, 'elyra': True, 'jupyter_lsp': True, 'jupyter_resource_usage': True, 'jupyter_server_mathjax': True, 'jupyterlab_git': True, 'nbclassic': True, 'nbdime': True}>}}
[W 2021-09-22 20:14:00.770 ServerApp] Failed to connect to URL for component: https://raw.githubusercontent.com/apache/airflow/1.10.15/airflow/operators/bash_operator.py: ('Connection aborted.', ConnectionResetError(10054, '远程主机强迫关闭了一个现有的连接。', None, 10054, None))
[W 2021-09-22 20:14:00.858 ServerApp] Failed to connect to URL for component: https://raw.githubusercontent.com/apache/airflow/1.10.15/airflow/operators/email_operator.py: ('Connection aborted.', ConnectionResetError(10054, '远程主机强迫关 闭了一个现有的连接。', None, 10054, None))
[W 2021-09-22 20:14:22.602 ServerApp] Failed to connect to URL for component: https://raw.githubusercontent.com/apache/airflow/1.10.15/airflow/operators/http_operator.py: ('Connection aborted.', TimeoutError(10060, '由于连接方在一段时间后没有正确答复或连接的主机没有反应，连接尝试失败。', None, 10060, None))
[W 2021-09-22 20:15:04.800 ServerApp] Failed to connect to URL for component: https://raw.githubusercontent.com/apache/airflow/1.10.15/airflow/contrib/operators/spark_sql_operator.py: ('Connection aborted.', ConnectionResetError(10054, '远 程主机强迫关闭了一个现有的连接。', None, 10054, None))
[W 2021-09-22 20:15:25.939 ServerApp] Failed to connect to URL for component: https://raw.githubusercontent.com/apache/airflow/1.10.15/airflow/contrib/operators/spark_submit_operator.py: ('Connection aborted.', ConnectionResetError(10054, '远程主机强迫关闭了一个现有的连接。', None, 10054, None))

[kevin-bates]

Yeah, I’m thinking the same thing after reading this issue. I don’t think that was necessarily “in the plans” as those kinds of issues aren’t immediately evident although should have been considered. I believe that when we move to a watchdog mechanism to accommodate async cache reloads (#2162) we should consider also addressing the initial load in a similar manner. In that case, perhaps the constructor could set up the watchdog, then touch the files, letting the update from the touch trigger the async (and initial) load from the watchdog observer thread.

[ptitzler]

@kevin-bates @kiersten-stokes (comment is not specific to examples but URL registry entries in general) - are we planning to load [remote] component specifications in the future in parallel and asynchronously? A sequential/blocking approach won’t work in environments where the registry includes many remote entries and network latency is an issue.