<table><tr><td style="">TallFurryMan added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D19393">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D19393#428066" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D19393#428066</a>, <a href="https://phabricator.kde.org/p/wreissenberger/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@wreissenberger</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>Shall I give it a try?</p></div>
</blockquote>

<p>Sure, and I have suggestions :) let's do this really step by step. At the extreme, because the source is so complex, I'd say let's go function by function, ensuring that they match features.</p>

<p>There are different stages I think:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Frame map consolidation. There is a local part in the job, and a consolidation part in the scheduler. Here job can be considered independent from scheduler I think. But it's easy to add regressions, as we observed last year.</li>
<li class="remarkup-list-item">Astronomical calculations for restrictions. It was difficult to make those independent from each other, and they rely on scheduler properties, so prototypes will be tricky. Besides, calculating some values in the future like dawn and dusk is still completely bugged. We won't be able to do that in one step.</li>
<li class="remarkup-list-item">Job state manipulation. This was mostly covered last year, but may still be fragile.</li>
<li class="remarkup-list-item">Serialization to/from storage. We had a discussion last year about switching to QT serialization instead of manipulating files. Should be a good opportunity to move forward.</li>
<li class="remarkup-list-item">Relation with sequence files. If we move that part we can do far better in terms of storage organization. For instance, it's annoying to require the end-user to build a sequence file with a target folder before a scheduler job can be started. The sequence file would still need the correct CCD to be connected to Ekos prior to be used, but at least we could start templating sequences used in the scheduler, replacing a few values only. That is too difficult to do for now with the code as it is.</li>
</ul>

<p>As a side note I want to make all jobs except the running one editable while scheduler is running, so that we'll be able to read schedules from an external source. Will be easier when code is moved away.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R321 KStars</div></div></div><br /><div><strong>BRANCH</strong><div><div>improve__bypass_aborted_jobs_while_running (branched from master)</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D19393">https://phabricator.kde.org/D19393</a></div></div><br /><div><strong>To: </strong>TallFurryMan, mutlaqja, wreissenberger<br /><strong>Cc: </strong>mutlaqja, wreissenberger, kde-edu, narvaez, apol<br /></div>