Gregor,
when creating KeyID builds with the new keyids *on the fly*.... will we
still be able to see if a string is in the *changed* status?
also can you may be summarize the advantages and desadvantages
(Community/Sun) of switching to new keyids?
Thanks,
Rafaella
Gregor Hartmann wrote:
Hi all,
We are thinking about a way to allow the community to do KeyID Builds
with the same KeyIDs used by the SUN KeyID builds.
It seems to be the easiest way to generate KeyID on the fly to get rid
of the IDs stored in SUNs Database.
What I want to ask is how long these IDs can get at maximum. Would an
ID of 8-12 characters still be short enough?
So please comment on this, even if you don't care about the rest of
the mail.
Technical Stuff:
Currently it is open on how to define these IDs.
It should be possible to generate them on the fly but more important:
They should be available immediately after a new string has been
introduced to the code.
So it seems to be clear that the ID has to be generated from some
fields in the sdf file including the project, file path, Resource
Type, GID, LID and HelpID. (fields 1,2,4,5,6,7)
However the exact algorithm is not determined jet. Maybe some CRC
which can be packed to alphanumeric characters will be OK. This
however bears the risk of duplicate IDs.
Another approach would be to store the IDs somewhere in the sources
and assign them. This leaves the problem of assigning new IDs for new
strings. A simple counter in the sources will not do since there will
be collisions when introducing new IDs in several CWSes simultaneously.
If you have any suggestion or other comments or just want to state
your favorite please let me know.
Thanks
Gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
