<div dir="ltr">Here are some ideas I have as a wishlist for gardening/improvements.<div><br></div><div><b>Client Models for DBus</b></div><div>Right now sdbusplus does a pretty good job of making server development easy.  However, I wish we had some more tooling on the client side. I see a decent amount of repeated code around ObjectMapper. </div><div><br></div><div>One way to separate concerns and cut down on boilerplate is to have a model library. A call to a model would spin off an async method call to manage the data marshalling, which would then call a lambda with a fully reified object.  This is similar in concept to the way models work in web development.</div><div><br></div><div><b>Unit Testing in bmcweb</b></div><div>This is pretty easy to say, and harder to do. I've been thinking a bit about how to add in unit tests without them being too fragile. (This was also something that geissonator mentioned).</div><div><br></div><div><b>DBus Virtualization and Playback</b></div><div>One thing that I think makes unit testing in some modules hard is that there is a high barrier around mocking DBus.  I'm not sure the best way to build this sustainably, but it would help improve our CI testing.</div><div><b><br></b></div><div><b>OpenAPI for Redfish</b></div><div>So far the general impression I've seen with this is that the Swagger output for OpenAPI isn't really good for C++.  Either the ergonomics aren't really good, or there is a lot of code bloat.  I'd love to have some OpenAPI bindings that work well in OpenBMC.</div><div><br></div><div><b>RUST!?!?</b></div><div>I'm betting a lot of people have thought about Rust. I'd love to hear what people have tried and what are the sticking points.  Any thoughts on what module/functionality could be a decent candidate for breaking ground here?</div><div><br></div><div>-Richard</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <<a href="mailto:rhanley@google.com">rhanley@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone,<div><br></div><div>Last week I started a thread on <a href="https://lists.ozlabs.org/pipermail/openbmc/2020-April/021100.html" target="_blank">Open BMC Gardening</a>, and I wanted to kick off the process.</div><div><br></div><div>The basic idea here is to get a survey of various improvement tasks throughout OpenBMC.  Some things might be small refactoring or changes that can be done incrementally (i.e. weeding the garden). Other tasks might be more research or structural (i.e. excavating the garden).</div><div><br></div><div>Just getting these in writing can be helpful for others to gauge what they should focus on. It also helps leave breadcrumbs for any new developer interested in the subject.</div><div><br></div><div>So here's how I see this working. Anyone who has some ideas can reply to this thread with a short to medium description.  Try to avoid new features, and instead look at ways we could improve the status quo. Think about changes and tools that would make your day to day life better.</div><div><br></div><div>From there we can do a write up about what we know about the issue.  This can function as an early stage design doc that gives a broad overview on where the dev's head is at right now.</div><div><br></div><div>Finally, we can do a quarterly review to keep the garden refreshed. Obviously, things can change between that time, but having a semi-regular cadence will hopefully give us a better chance of keeping this up to date.</div><div><br></div><div>- Richard</div></div>
</blockquote></div>