libcompose icon indicating copy to clipboard operation
libcompose copied to clipboard

[Proposal] Code refactoring for async commands.

Open kunalkushwaha opened this issue 9 years ago • 3 comments

With reference to https://github.com/docker/libcompose/pull/290#issuecomment-224812179

Commands like start, up, rm, down etc, which result in async action and result obtained not in context of command execution. The error handling and result based actions are currently performed within functions with no clear patterns. Since Project Events and docker-events are accessible, a little refactoring will make all such command simple and easy to maintainer.

Proposal:

  • Processing error/events using channel in calling function. e.g.

func (p *Project) Up(ctx context.Context, options options.Up, services ...string) error {
    return p.perform(events.ProjectUpStart, events.ProjectUpDone, services, wrapperAction(func(wrapper *serviceWrapper, wrappers map[string]*serviceWrapper) {
        wrapper.Do(wrappers, events.ServiceUpStart, events.ServiceUp, func(service Service) error {
            return service.Up(ctx, options)
        })
    }), func(service Service) error {
        return service.Create(ctx, options.Create)
    })


  // Listen for error or completion on Channel.
  // Using context.Context and  
 select {
    case <-ctx.Done():
        <-errorChannel // Wait for f to return.
        return ctx.Err()
    case err := <-errorChannel:
        return err
    }
}

kunalkushwaha avatar Jun 10 '16 08:06 kunalkushwaha

I'm not sure I completely follow the explanation/example but yeah refactoring is needed. The first I'm working on though is the Container struct.

vdemeester avatar Jun 10 '16 09:06 vdemeester

@vdemeester Can we create a separate issue for refactoring around Container? I'm just curious what the high-level goals are, particularly with respect to the Container project interface.

joshwget avatar Jun 10 '16 16:06 joshwget

Sorry for not clear example.

Basically instead of handling event based action in callbacks or deep under some functions, actions should be taken from main function of that functionality.

e.g. In Log(), "die" , Event can/is handled in service.go, which works well. But for functions like Up() Where error or event, which ever comes first, different actions need to be taken. If some channel based communication is setup, a framework for handling errors and events can be created.

kunalkushwaha avatar Jun 13 '16 05:06 kunalkushwaha