[Kstars-devel] More (old) thoughts on AuxInfo hash

[Alexey Khudyakov]

On Thu, Jun 11, 2009 at 10:57 PM, James Bowlin<bowlin at mindspring.com> wrote:
> On Thu June 11 2009, you wrote:
>> On Friday 05 of June 2009 15:19:54 Akarsh Simha wrote:
>> > But I have always wanted to have a UUID for every object in
>> > KStars. This might be hard stuff, but it would be nice if every
>> > object carried a few bytes of its own UUID. Maybe it's not required
>> > - except for unnamed stars - where it will be rather useful to have
>> > a UID, or even a legitimate catalog number attached.
>>
>> If we want to separate AuxInfo from SkyObject it's not a good thing
>> to do. It rather mandatory.
>
> I disagree, although we might want/need a UUID for other reasons.  For
> example, storing all AuxInfo data in a hash will make it easier to
> save (to disk) and restore all the AuxInfo information.
>
> To me, the key thing is that AuxInfo stores user input so the number of
> AuxInfo objects actually used will be small (compared to the number of
> unnamed stars, or even the number asteroids).
>
> Here is an easy way to only hash AuxInfo for stars.  The AuxInfo field
> in StarObject should be a pointer whose default value is NULL.  For most
> objects when an AuxInfo field is to be accessed, the pointer is checked
> for NULL.  If it is NULL, we create a new AuxInfo object and fill the
> pointer with its address.
>
> For stars, we do almost the same thing, but when it is time to create a
> new Auxinfo object (because the pointer was NULL) we first check the
> hash to see if an AuxInfo already exists for this star.  If a pointer
> already exists in the hash then we use it, otherwise we create a new
> AuxInfo object and add the pointer to the hash in addition to using it
> to fill the field in the star object.
>
> One benefit of this scheme (in addition to being very simple) is that
> we don't need to come up with a UUID for every single object all at
> once. That way we can start hashing AuxInfo for stars ASAP (because
> what we have now is broken IMO) and then take our time to design the
> UUID correctly without feeling pressured.
>
> These ideas were already discussed a year ago.  The earlier discussions
> can be found with Google(kstars-devel auxinfo).
>

This scheme is simple but it has a number of problems. First of all is
saving/loading. When AuxInfo is loaded and it doesn't belong to star. Then we
must find this object and attach AuxInfo to it. Identification of such object
would require some kind of UUID anyway.

Second is that AuxInfo is scattered through all objects. It's better to keep
all AuxInfos in one place I believe. This way it easier to manage them. I.e.
list/search/edit/delete. I think Prakash could say more on this matter since
he's working on observing lists.

Simplest UUIDs for object beyond Solar System are coordinate hashing I
believe. Alternative is hand made numbers. There is no problems with big
planets. Asteriods have unique numbers assigned to them by IAU AFAIR. Don't
know anything about comets. So UUID design is really big problem.
And as long as we do not save UUIDs between kstars runs we are free to
change numbering scheme.

UUIDs are useful not only with AuxInfo problem. It makes possible to
associate some data with skyobject. For example objects' proper names may
be stored in the same way as AuxInfo. Probably it could solve at least some
of localization troubles. It would be possible to "attach" multiple catalog
entries to object.

UUIDs provide covenient way to handle sparse data and to implement 1-to-n
relations.

So I think implementing UUIDs worth its efforts.