<div dir="ltr">Cleber, yes, I agree with the points raised there, design-wise. I also like the proposal of having best practices for modular/extensible parts of the design.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 1, 2015 at 12:31 PM Cleber Rosa <<a href="mailto:crosa@redhat.com">crosa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
I've been doing some research and prototyping these last days, and I<br>
reached one specific point that I'd like to discuss early and openly.<br>
<br>
The point is about the Avocado UI, and how we have pretended that<br>
`avocado.core.output.View` follows some interface and could allow us<br>
to switch one View (or UI) for another one. I reckon that, by not<br>
having swappable Views (UIs), our design can be (actually is) broken.<br>
<br>
So the proposals here are:<br>
<br>
1) We should document, and maybe enforce, the interface that different<br>
   components in Avocado expect and provide.<br>
<br>
By documenting, it could be as simple as:<br>
<br>
   # avocado/core/ui.py<br>
   class Base(object):<br>
       def setup(self):<br>
           raise NotImplementedError<br>
    def notify(self, event, msg='', **kwargs):<br>
           raise NotImplementedError<br>
    def teardown(self):<br>
           raise NotImplementedError<br>
<br>
Or we could enforce the implementation of these interfaces by using<br>
Abstract Base Classes:<br>
<br>
   # avocado/core/ui.py<br>
   import abc<br>
   class Base(object):<br>
       __metaclass__ = abc.ABCMeta<br>
<br>
        @abc.abstractmethod<br>
        def setup(self):<br>
<br>
        @abc.abstractmethod<br>
        def notify(self, event, msg='', **kwargs):<br>
<br>
        @abc.abstractmethod<br>
        def teardown(self):<br>
<br>
2) Having these interfaces defined, there should be at least two solid<br>
   implementations that are tested in unittests and functional tests.<br>
<br>
   class Silent(Base):<br>
      def setup(self):<br>
          pass<br>
<br>
      def notify(self, event, msg='', **kwargs):<br>
          pass<br>
<br>
      def teardown(self):<br>
          pass<br>
<br>
    ---<br>
<br>
    class Curses(Base):<br>
       def setup(self):<br>
           import curses<br>
           window = curses.initscr()<br>
<br>
       def notify(self, event, msg='', **kwargs):<br>
           self.window.insstr(msg)<br>
<br>
       def teardown(self):<br>
           curses.endwin()<br>
<br>
The point is that a `--silent` option SHOULD be implemented by<br>
swapping the current UI "driver", and nothing else.<br>
<br>
The UI example given here is not a big deal code-wise or even<br>
functionality wise, but the same mentality and design should be taken<br>
to other areas. Running a test remotely or on a container or on a<br>
cloud instance should be a matter of swapping "test execution drivers"<br>
and that's all.<br>
<br>
My idea, given positive feedback, is to improve the current state of<br>
things in the UI layer first, and make guidelines/best practices for<br>
the other areas that should modular and extensible in Avocado.<br>
<br>
Cheers,<br>
Cleber Rosa.<br>
<br>
_______________________________________________<br>
Avocado-devel mailing list<br>
<a href="mailto:Avocado-devel@redhat.com" target="_blank">Avocado-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/avocado-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/avocado-devel</a><br>
</blockquote></div>