Hello Gal,

Gal Zaidman [2020-03-18 17:38 +0200]:
> I think that you have miss understood my intention, I aim to create a
> separate development environment which will use webpack-dev-server.
> I don't want to login with cockpit UI,
> I want the that the js will be served by webpack-dev-server and not
> cockpit-ws (It will have to run in the background but I will not use
> cockpit UI),
> that is why I needed to link to base1 in the dev env.

I'm afraid this doesn't work. You *have* to use cockpit-ws if you want your
code to do anything with the base1 cockpit API, as the communication is done
over a websocket to the bridge. Any other web server does not do this.
You may be able to test some initial pure UI bits, but that won't  get you very
far.

But there is really no reason to be afraid of cockpit-ws -- it runs
unprivileged, you can even start it as your own user with
/usr/libexec/cockpit-desktop (see its manpage). Yesterday I even sent a PR to
teach cockpit-desktop to start the bridge (i. e. the machine that you want to
look at in Cockpit) on a remote ssh host:
https://github.com/cockpit-project/cockpit/pull/13754
It didn't land yet, but it's trivial to apply the change locally. If you are
interested in this route, I can tell you the details.

You can still use things like `webpack --progress` to efficiently build your
pages, of course. You just need to symlink your build directory to
`~/.local/share/cockpit/yourproject, or scp it into your test machine
(depending on where you want to run cockpit-ws).

> So I basically need to have what you cockpit-es --> cockpit session -->
> Remote machine bridge.
> But I need to configure it with the CLI and not via cockpit UI, I know that
> I can start cockpit service like a normal service with systemctl

I'm afraid I can't parse that properly. I still don't understand what exactly
you are trying to do. Perhaps take a step back and don't try to explain *how*
you want to do things ("CLI, "cockpit-bridge", "webpack dev server"),  but
*what* you want to do?

> BTW one big reason that I don't want to refresh is that I'm working with
> modal on a process which runs ansible scripts which can take a lot of time
> to execute and a refresh will send me back.

What is "modal" here, do you mean your UI opens modal dialogs that run Ansible
scripts? If merely reloading your page is so expensive, then I suppose you
should rather redesign it. Cockpit pages should not trigger long-running,
un-interruptible/resumable actions like that.

It might be easier if you say hello in #cockpit on Freenode, so that we can
discuss this more interactively?

Martin
_______________________________________________
cockpit-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]

Reply via email to