How to implement the funtionality?

[HojaeAhn]

I want to raise an issue of where the algorithmic code should go.
I drew a simple diagram representing my question.

Here are two options to put the algorithmic code: 1) in the commands (e.g. /lvmagp/python/lvmagp/actor/commands/slew.py) 2) in another python file (e.g. lvmagp/python/lvmagp/actor/commfunc.py, hereafter I'll say it as 'module file')
The science team members don't want to use cluplus and deal with actors, and they just want to use the function inside the API module (like the bottom text box). So I agree on the need for an additional file (module file) separated from the command-defining file (the right text box of each method).
The point is we can put the algorithmic code inside either the command-defining file or module file. If we put the algorithms in the command file, then inside the module file, we just make an AMQP client and call the agp function. If we put the algorithms in the module file, we call the function in API when the command is executed.

I interpreted that your intention in issues was the second one, and I am revising the code following that way. On the other side, according to my understanding, Changgon is making lvmscp using the first method, and it may reduce the developing time because it just uses the existing command.
So I want to show both methods and hear your opinion.

[wasndas]

Actually I do have a more radical 3rd aproach, throw out the slew command,
because it seems to be implemented in lvmops:tel_interface
Maybe the lvmagp should just guide and expect that the telescope is a the right position
and it does only guiding and focusing.

[wasndas]

... but actually same thing for the focus functionality lvmops:autofocus :-]

[wasndas]

Maybe I misunderstood the question, it was not lvmagp centric. It was probably more a general question about duplicated implementation in lvmops and lvmagp + lvmscp.

Algorithmic code and parameters should be seperate in a class/module (Method2), so that it can be used by others. Thats why I created this lvmtipo where I put all this type of code, eg fieldangle, targetpos, ... Then you can also add easily a command line interface for manual testing.

Since lvmtipo doesnt have any dependecies to other lvmXXX it can be used by them and it doesnt use any actor clients.

[HojaeAhn]

OK, I could understand what you mean. I will put the algorithmic code in the module file.
By the way, as you mentioned here and I mentioned in the last meeting, we can put the algorithmic code in lvmops directly without lvmagp. Then the lvmops control all devices including the scope of lvmscp and lvmecp. In other words, the lvmops will be equivalent to the sum of lvmagp, lvmscp, and lvmecp. So it was a more fundamental question about the needs of intermediate-level actors like lvmagp. I guess what I'm making, the module file of lvmagp (commfunc.py), is a part of lvmops and it might be merged into lvmops in the future.

[wasndas]

Yes I do fully agree, we should discuss things like that on Monday. I have put it already in my list of discussion points here as lvmagp vs lvmops controlling lvmpwi

Btw, I have created a github super project with all lvm packages involved here, if I have missed one package please tell me.

[HojaeAhn]

I would like to suggest adding an agenda about the identity of the lvmops; Should the lvmops be the actor or the module? I have regarded this as the most important point to decide the development direction.
I checked the lvm superproject, and it seems there is no missing package :)

[wasndas]

Yes. Ill do.