11 Replies
hey things go slowly but surely - it's starting to take shape, but ive been p busy lately. gonna keep at it this weekend tho and hopefully get a proper draft out
awesome stuff. lmk when you feel confident enough for me to find a date for the review.
the weekend of 24-26th should be good with me, but ill have something for you to take a first look at hopefully this weekend, if not then def next weekend
I'm starting to approach something I like - there's a fair bit of stuff im leaving out rn bc I haven't finished it, but it does rely on this part:
nice! only thing i'm not a fan of is the normalizer API, the rest of it is a good API shape (obviously there's nits that are easier to review when it goes to PR but this isn't extreme). also the axis device registry, this likely shouldn't be static. I'd imagine a non-static version of this is what will end up in input context or a related API that can interact with an input context.
thanks for the feedback! ill incorporate that and mull things over
from a composability perspective, how do you feel about this?
@Perksey Here's my latest "complete" version - not quite in Proposal Format, but I think all of the information is there for Ground Zero Axis Control
Oh god sorry meant to look at this today
I’ll try and look at this once I get home but I might not be able to until the morning (afternoon)
haven't seen anything I dislike, but do want to try and make it slightly more lean (mainly wrt the extensions). we should hop in a call at some point. e.g. virtual vs non-virtual devices (although I do see your intention, and maybe this should be its own extension proposal mainly so the approval of the axis concepts as a whole - for which I do approve of this proposal's interpretation - is not contigent on the approval of some of the more cooler-but-involved use cases that we get from approving such an API), and an audit of some of the extension methods, etc - all of which is probably best done in a PR format
some similar comments from last time still apply but again these are probably best done at the PR stage so they're more trackable and individually discussable
ok sounds good! so do you suggest removing/separating the "remapping" and "extension method" sections?
also im down to chat at some point tomorrow if youre around - if not then next weekend
remapping definitely, the extension methods may be fine we just need to make sure every API is well-understood and well-rationalised. there are a lot of APIs there is my main worry, which isn't necessarily a problem but could cause a headache for ongoing maintenance
yes sir 🫡 most of the extension api are basically just overloads/utility methods that should in theory be write-once-and-forget . im down to trim the fat to its necessary parts, but i think at least some of the others would necessarily follow