Translate all synchronous commands to their async counterpart

[mariotoffia]

No description provided.

[SeanFarrow]

Is this under development, or is somebody working on this?
I'd love to help where possible.

Thanks,
Sean.

[mariotoffia]

Hi @SeanFarrow and sorry for late reply. No I haven't started - my aim was to create a "driver" like layer so it would be possible to use docker daemon communication as plugins and provide with a "standard" plugin using docker binaries.

That layer should be completely asynchronous. But if you'd like to translate existing commands into their asynchronous counterparts I would be happy!

Since those should be added in it's own namespace, we do not need to handle backward compatibility and hence re design the commands a bit so they are easier to maintain and extend in future without breaking compatibility.

Cheers,
Mario :)

[SeanFarrow]

Hi Mario, Don’t worry about the time to reply, I know how busy people get. Three questions before I start: Firstly, what .Net frameworks do we want to support? Secondly, is there any reason you want to depend on the Docker binary, it might make sense to take a dependency on Docker.Net and use that as a base layer. If you agree with this, I’ll raise a separate issue and transform the code first, then move to a fully asynchronous model. Finally, do we want to keep the synchronous code around—if yes, should this be obsolete/deprecated? Thanks, Sean. From: Mario Toffia ***@***.***> Sent: Thursday, February 16, 2023 7:04 PM To: mariotoffia/FluentDocker ***@***.***> Cc: Sean Farrow ***@***.***>; Mention ***@***.***> Subject: Re: [mariotoffia/FluentDocker] Translate all synchronous commands to their async counterpart (#21) Hi @SeanFarrow<https://github.com/SeanFarrow> and sorry for late reply. No I haven't started - my aim was to create a "driver" like layer so it would be possible to use docker daemon communication as plugins and provide with a "standard" plugin using docker binaries. That layer should be completely asynchronous. But if you'd like to translate existing commands into their asynchronous counterparts I would be happy! Since those should be added in it's own namespace, we do not need to handle backward compatibility and hence re design the commands a bit so they are easier to maintain and extend in future without breaking compatibility. Cheers, Mario :) — Reply to this email directly, view it on GitHub<#21 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALDK7UVNEG7BHF64K55OA3WXZ2YHANCNFSM4CCTSLVA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mariotoffia]

Three questions before I start:
Firstly, what .Net frameworks do we want to support?

I have been quite conservative so I won't break any existing code - but please suggest if any real value upgrades (i.e. dropping any) is worth while! I must admit that I do not know what users of this lib actually use. My reasoning was to support a Full framework and the .NET standard ones since they do have much support.

Secondly, is there any reason you want to depend on the Docker binary, it might make sense to take a dependency on Docker.Net and use that as a base layer. If you agree with this, I’ll raise a separate issue and transform the code first, then move to a fully asynchronous model.

Yes, I do depend on docker for three main reasons:

1. No dependency on other project than docker (of which is the main actor) to talk to docker - I do not need to rely on they fixing/implementing. This was "half-dead" when I started (I actually went for it in the beginning). I will also drop sharpcompress in next MAJOR and strive to remove as much as possible of dependencies for this reason.
2. Easy to reproduce/debug using the CLI (log outputs the docker command being used) - both users of this library uses this to debug and suggest/implement new functionality since "everyone" knows docker CLI. This has been quite useful and still is.
3. Docker is rather good to maintain backwards compatibility. At least in early days, communication with the daemon was quite messy. This allows for not need to update functionality all the time.

I think a better way is to implement the plugin model asynchronous and embed docker (commanding) into the main assembly and create new assembly that includes this one and hence if anyone wants use Docker.Net as backend they just need to use that as a reference and still get a complete environment.

Finally, do we want to keep the synchronous code around—if yes, should this be obsolete/deprecated?

• If aiming at next MAJOR then those should be removed in favour for the plugin architecture -> but that's a quite undertaking! since it is not just the plugin and async that is in that queue!

• If the current MAJOR it is a no-go to remove the existing code since it will break backwards compatability. In this case we use a separate namespace that isolates the async versions from the synchronous and in the next MAJOR remove those. However, they may be set in deprecated mode in this release.

Cheers,
Mario

[SeanFarrow]

Hi, For everything I’m thinking about/looking at, it would explicitly be for the next major version. I think we could probably get away with the following TFM’s: .Net Standard 2 and 2.1 (this gives you .Net framework support and support back to .Net core 3.1.) .Net 6 and 7 explicit support. Do y6ou have any documentation/notes as to how you want the plugin architecture to work. Once I get a handle on what you are thinking, I can start work on it to help you. Thanks, Sean. From: Mario Toffia ***@***.***> Sent: Saturday, February 18, 2023 1:01 PM To: mariotoffia/FluentDocker ***@***.***> Cc: Sean Farrow ***@***.***>; Mention ***@***.***> Subject: Re: [mariotoffia/FluentDocker] Translate all synchronous commands to their async counterpart (#21) Three questions before I start: Firstly, what .Net frameworks do we want to support? I have been quite conservative so I won't break any existing code - but please suggest if any real value upgrades (i.e. dropping any) is worth while! I must admit that I do not know what users of this lib actually use. My reasoning was to support a Full framework and the .NET standard ones since they do have much support. Secondly, is there any reason you want to depend on the Docker binary, it might make sense to take a dependency on Docker.Net and use that as a base layer. If you agree with this, I’ll raise a separate issue and transform the code first, then move to a fully asynchronous model. Yes, I do depend on docker for three main reasons: 1. No dependency on other project than docker (of which is the main actor) to talk to docker - I do not need to rely on they fixing/implementing. This was "half-dead" when I started (I actually went for it in the beginning). I will also drop sharpcompress in next MAJOR and strive to remove as much as possible of dependencies for this reason. 2. Easy to reproduce/debug using the CLI (log outputs the docker command being used) - both users of this library uses this to debug and suggest/implement new functionality since "everyone" knows docker CLI. This has been quite useful and still is. 3. Docker is rather good to maintain backwards compatibility. At least in early days, communication with the daemon was quite messy. This allows for not need to update functionality all the time. I think a better way is to implement the plugin model asynchronous and embed docker (commanding) into the main assembly and create new assembly that includes this one and hence if anyone wants use Docker.Net as backend they just need to use that as a reference and still get a complete environment. Finally, do we want to keep the synchronous code around—if yes, should this be obsolete/deprecated? * If aiming at next MAJOR then those should be removed in favour for the plugin architecture -> but that's a quite undertaking! since it is not just the plugin and async that is in that queue! * If the current MAJOR it is a no-go to remove the existing code since it will break backwards compatability. In this case we use a separate namespace that isolates the async versions from the synchronous and in the next MAJOR remove those. However, they may be set in deprecated mode in this release. Cheers, Mario — Reply to this email directly, view it on GitHub<#21 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALDK7W3WL7OCL6KSQKDQGTWYDBYZANCNFSM4CCTSLVA>. You are receiving this because you were mentioned.Message ID: ***@***.***>