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

[Akarsh Simha]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20110116/99132bf2/attachment.sig