From: "Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@linux.intel.com>
To: Jeremy Kerr <jk@codeconstruct.com.au>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>, Ed Tanous <ed@tanous.net>
Subject: Re: Virtual Media repository request
Date: Mon, 20 Dec 2021 13:54:57 +0100 [thread overview]
Message-ID: <592e3b4d-2125-22b7-2413-0aa0857c9fe8@linux.intel.com> (raw)
In-Reply-To: <8857fb3c25b2e3918dcda00f04710b3e9f84f1d9.camel@codeconstruct.com.au>
On 17.12.2021 10:45, Jeremy Kerr wrote:
> Hi Przemyslaw,
>
>> I am ok with that approach, but I just wanted to separate service code
>> and JS nbd server, as they are quite distinct entities from my
>> perspective.
>
> The actual nbd server code is tiny; only around 260 lines of javascript.
> I don't think it's worth keeping a whole repo for that, given we would
> not be using the jsnbd/nbd-proxy code.
>
> So, I'd suggest just including this with the new VM implementation, or
> moving it alongside the rest of the web ui.
Ok, got it.
I plan to start pushing changes here this week.
There is just a one thing to be determined.
Currently, the "proxy" mode handler for websocket in bmcweb is defined
as /vm/0/0 (see include/vm_websocket.hpp:161).
New service handler (to be found in include/nbd_proxy.hpp) requires
websocket defined as /nbd/<str> as more slots can be available.
This breaks the old API.
I believe there should be a kind of migration period for applications
that use old location and format before the old one is turned off.
For /nbd location there is already implemented UI module to handle that
(but needs to be enabled).
Who is aware of such applications?
>
> Cheers,
>
>
> Jeremy
>
--
Best regards,
Przemyslaw Czarnowski
next prev parent reply other threads:[~2021-12-20 12:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 15:50 Virtual Media repository request Hawrylewicz Czarnowski, Przemyslaw
2021-12-08 16:56 ` Patrick Williams
2021-12-09 8:56 ` Czarnowski, Przemyslaw
2021-12-09 10:41 ` i.kononenko
2021-12-13 16:10 ` Patrick Williams
2021-12-13 19:44 ` Czarnowski, Przemyslaw
2021-12-14 2:11 ` Jeremy Kerr
2021-12-15 19:26 ` Ed Tanous
2021-12-17 9:28 ` Czarnowski, Przemyslaw
2021-12-17 9:45 ` Jeremy Kerr
2021-12-20 12:54 ` Czarnowski, Przemyslaw [this message]
2021-12-23 1:01 ` Czarnowski, Przemyslaw
2022-12-19 14:01 ` Czarnowski, Przemyslaw
2022-12-19 17:43 ` Ed Tanous
2023-01-03 5:36 ` Jeremy Kerr
2021-12-11 21:13 ` Ed Tanous
2021-12-13 19:17 ` Czarnowski, Przemyslaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=592e3b4d-2125-22b7-2413-0aa0857c9fe8@linux.intel.com \
--to=przemyslaw.hawrylewicz.czarnowski@linux.intel.com \
--cc=ed@tanous.net \
--cc=jk@codeconstruct.com.au \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.