@pawel Thanks for helping, I really can't make new pyindi-client versions as updates are commited in the indi-core master branch. IMO this may not be the best way, as you may have to add code because of swig limitations, code that you are going to suppress on the next indi-core release as you want to keep it as simple as possiblle.
I made pyindi-client years ago, just to see if this was achievable at low cost (I remember I started with using another wrapping tool, SIP). And I was unaware that it was used in subsequent projects since then.
I've proposed to @pawel to include pyindi-client directly in indi-core. I just can't support it alone.
@dolguldur and @GuLinux Don't wait a support for npindi. Really too large.
@dedicateastro The docs for pyindi-client are the C++ docs for IndiClient. No more, no less (almost). I don't want to write a documentation on how to design an indi client.
Mmh, what do you mean by "too large"?
As I mentioned, I was thinking of either creating a new native python client, or possibly joining efforts with an existing projects. What are your thoughts on that? Is npindi too complex?
npindi is basically a python rewrite of some indi base class in addition to the indi client qt classes used in kstars. That are those "kstars" qt classes which need some work if you want to stay in sync.
With current pawel's work the indi base class may also need some rewriting. Now, as long as the INDI xml format remains unchanged, npindi should continue to work whatever implementation is used in C++.
If you only need a basic client (I suppose you only need to translate INDI messages into JSON format and send that through a webservice), you may only keep or start from the npindi base class. In your case you may even suppress the receiving thread if your client has nothing else to do. Mmmh, maybe should you also listen to your app...