Welcome to SlipLib Discussions!

[rhjdjong]

👋 Welcome!

First of all, my apologies if this is not relevant to you. In this message I mention all GitHub users that have starred or cloned the SlipLib repository, to make them aware of this announcement. I don't plan to make a habit of that, so you will not receive further notifications in this way.

This is the place where I want to discuss the future development of SlipLib. I know of several users and clones of this package, and I want to avoid if possible that any upcoming changes cause problems for them.

One thing that I am working on at the moment is proper async support, in that a user can either use the current (blocking) synchronous method to get the next SLIP message, or use a (to be added) async method for that purpose.

During my investigations on this I found that I need to restructure the package. Currently the SlipWrapper combines several functions:
providing the high-level interface, buffering of SLIP messages, handling of protocol errors, and interacting with the low-level Driver and bytestream.

One of the things I plan to do is move the buffering of messages into the Driver, and separate the processing of received bytes from getting a message to the user application. So instead of having Driver.receive() return a list of messages, it will return None. A new interface method, let's say get_message() will return the next buffered message (or None if no message is available).

This will of course change the interface to the Driver class, and the internals of the SlipWrapper class and its subclasses.
What I would like to know is if the users of SlipLib have defined their own subclasses of SlipWrapper and/or are using the low-level Driver class directly,

Thanks in advance for letting me know.

Ruud

Mentions

@SuperErnD @darthcloud @Overboard @FARLY7 @yuki-inaho @krthr @TylerWhittaker @potens1 @kb1lqc @MitchRatquest @xixiaxixi @jevinskie @rizickus @Raghav-Soni @zcattacz @stevenenggarK @StarDylan @SeasideLookout @cubic3d @zinwalin @rdroste @jackwilsdon @kissste @smcveigh-phunware @samvasko @UBIKsolutionsOU @ericyao2013 @olevett @valerie9