[Kstars-devel] Re: Splitting KStars architecture into database, libs and UI.

[Henry de Valence]

Perhaps this message should be cross-posted to other mailing-lists,
like the Stellarium one.

On 16 January 2011 18:30, Akarsh Simha <akarshsimha at gmail.com> wrote:
> Hi
>
> Astronomy software, as I'd view it, are essentially meant to process a
> bunch of data and represent it well.
>
> Now, KStars has some very interesting features already which could do
> wonders if scriptable.
>
> Imagine these use cases:
>
> 1. Every month, you want to run checks for all possible conjunctions,
>   and put them in your calendar.
>
> 2. You want to generate a table of rise times of Venus across the
>   year, and plot them to analyze the data.
>
> 3. You want to query the star database around an open cluster to plot
>   a H-R diagram for educational purposes.
>
> 4. You want to automate your deep-sky observations -- feed in your
>   observing session plan, find star-hopping routes to each DSO, and
>   print finder charts covering the entire star hop.
>
> KStars currently has all the machinery to handle these problems. It's
> just that they are not exposed in a powerful manner.
>
> There are other problems -- as star catalogs are expanding, astronomy
> programs unnecessarily duplicate the effort of adopting the data into
> their software. Stellarium is already at 600 million stars, while we
> are still back at 100. And we will probably never reach the database
> quality of Cartes du Ciel (They released their stable Linux version
> 3.2 recently! Do check it out!). Now, we will need to duplicate their
> efforts if we need to incorporate these databases into KStars. On the
> other hand, because all our file formats are different, the user needs
> to install multiple copies of the same data in different formats. I
> right now have two copies of Tycho-2 installed -- one for KStars and
> one for CdC.
>
> I just had an interesting discussion on IRC (##astronomy) today and
> someone suggested that the best way of dealing with this is an n-tier
> architecture, where we separate into:
>
> 1. Database Engine -- storing and retrieving data appropriately
>
> 2. Computational Engine -- which computes all the things we would ever
>                           need to
>
> 3. User Interface -- which displays outputs, provides interfaces to
>                     query the database and the computational engine.
>
> Victor has already succeeded in delegating the data handling to a nice
> database engine for Deep Sky Objects.
>
> A lot of our tools are already written with separate backends and
> frontends (but they don't read the data right, or use KStars-specific
> data structures)
>
> IMO, we should attempt at making this separation. And it would be even
> awesomer if all the astronomy software adopted a common database
> backend, and possibly even a common computational engine, and differed
> just in the UI.
>
> Separating the database engine would avoid the effort duplication I
> mentioned. Already, we have a shortage of people who work on astronomy
> software (some Stellarium devs complained about the same problem). CdC
> is an almost one-man effort, AFAIK. And doing something like this
> would save a lot of manpower. Our GSoCs could help Stellarium and CdC
> indirectly.
>
> There's already libnova, which KStars mentions as an optional
> dependency, but does not use AFAIK. Instead of contributing to N
> different astronomy software, we could just use libnova (provided it
> is cross-platform etc)
>
> An outlook of this form would mean progress, because one could build
> any sort of UI one wants to over these backends -- a web interface, a
> mobile app that queries servers to get its data, a fancy OpenGL
> interface, a traditional no frills interface, or a bunch of shell
> scripts that do what I want them to.
>
> I'd welcome thoughts on this.
>
> Regards
> Akarsh
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJNM3+IAAoJENfUWi5BqyX597oP/2KTKgqMZ7IPez3De9ikXsY9
> DIPAxW3MHuFDMnJR0k8OT9uitZC0o0VUCf+fYPo+dr0wNv3BXjbuO0s85w0OtRMD
> IY7t4xfuv860oakKhObuOQjVAMH07clr/ozufHxNX9Y+gChfNCyfR9AFQdh7x96P
> SbE+Q/E34sSvFQhnBR9hK5PIV5NvgkAG3jR8qIIHHnKZJWr7qhU+QaU2yG8rhjOL
> VRBBeCF6C1gRNLMoG/3q8wM436WWEbTYIm3TLhjviBwJVZ9LqvHA98IlJ+J90JpN
> dODbAZXrXMuWZBCsajLb0Op6yaZYGTQRDe3dBOVrseKwbw841/qeUrC0CusCYDxu
> 45qVNMhue0Jqc3H7gXAjxQNDD+rFc7rCd6fr9lGVThzmsZe68Rpn2DM1bQzuNBYd
> I/QJKZx1x7RW+jNB4bvO0WkxknsOVUhd1DRDeQXvX/wKntyBJUI0vGaAhEc5/sCt
> 7phzQQljTT48MlYdziODmJlVAIz0BRepfdKrWS9kUqkocDVrPttkVg+mxFxi4lHp
> hyUXoHN+Np0aBIBstDnGRV4RbcDbw68X7ZV0KAyE1vLg7CuxKL2NJJoz9t2DJ/y4
> jKd/Ln23FrNH+FVNfm5NHftmabhiRe31feWYuFNQVRrbIIVUANye/aWaEv625+6b
> GJqIfxEaJT861xpTMgBE
> =9f5t
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>
>