VK:
What I think your describing is an inherent difficulty
in any sort of distributed database: how to insure that the most
meaningful information is not lost?
So for example, I start Kaboodle on PC1 for the first time.
I setup my LAN and my Groups as I want them. I then start Kaboodle
on PC2 for the first time, and it gets this NID. So far so good.
Then I shutdown PC1 and work on PC2 for a while, making more
changes to my LAN and my Groups. Then I shutdown PC2.
I now have two different, unsynchronized NIDs on my LAN.
If I start Kaboodle up on PC1 first and then PC2, the NID on PC2
will be discarded. Conversely, if I start Kaboodle up on PC2, the
NID on PC1 will be discarded.
The easiest way to work with this uncertainty is to presume
that whatever NID is running on the LAN is the most recent one. So
whenever Kaboodle joins a network, it should presume that there's
a useful NID already in existence and should query for it. If there
isn't one, it should then assert its own. It should never assert
its own if there is a NID on the LAN.
So in your example, when PC2 starts up with groups C and
D in its NID, it should discard that information and presume that
PC1's NID is correct. So PC2 then displays groups A and B.
The only other way I can see if handling this is to have
some sort of "seniority" field in the NID. It records how long, in
seconds, the NID has been valid. So if PC1 is running Kaboodle for
a week and is then shutdown, it's NID will have a seniority value of
604800. If PC2 is then started up while PC1 is down, it will create
its own NID. Then PC1 comes back online in an hour, and we check
604800 on PC1 to 3660 on PC2. PC2 would then discard its NID and
take its NID from PC1.
For now, though, I'm comfortable not using such a seniority
field.
-Scott
On Wed, 24 Jul 2002, mailbox wrote:
> Hello Scott,
> Please take a look at the following example:
> On PC1 - there are two groups named "a" and "b" and on PC2-there are two
> groups named "c" and "d".
> Let us assume that PC1 is running kaboodle. After that I start the PC2 with
> above data.
> The PC2 send its information and PC1 also sends its NID information to PC2.
>
> Case 1:
> Due to this information exchange I will get "c" and "d" on PC1 and "a" and
> "b" on PC2 as both the groups in NID have the same sequence information.
>
> If I keep "a" and "b" on the PC1 then what should be the sequence of these
> groups?
>
> Case 2:
> If I discard the group "a" and "b" on PC1 then NID Synchronization process
> will fail totally as one pc will show groups "a" and "b" and other will show
> "c" and "d"
>
> There is a lot of confusion on which information to keep and which one to
> discard. I think the NID synchronization with groups is not feasible. Please
> suggest a remedy for the same.
>
> Regards,
> Varsha
>
>
> ----- Original Message -----
> From: "Scott C. Best" <[EMAIL PROTECTED]>
> To: "mailbox" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 23, 2002 5:23 AM
> Subject: [Kaboodle-devel] Re: NID synchronization problem
>
>
> > VK:
> > Yes, good idea: Group names should be forced to be
> > unique when they are added or when the user tries to modify
> > a Group name.
> >
> > -Scott
> >
> > On Mon, 22 Jul 2002, mailbox wrote:
> >
> > > Hello Scott,
> > > There is a problem in implementing the NID synchronization. How I can
> > > find uniqueness of the devices of type Group and services? (For other
> > > type of devices the machines physical address is used to identify the
> > > device on the network and if the device is already there in the NID we
> > > only update the properties of that device otherwise we add the device to
> > > the NID.) Please suggest the remedy to the problem.
> > >
> > > My suggestion: We can use the device name for groups and services and
> > > put the restriction for the unique group name while adding the new
> > group.
> > >
> > > Regards,
> > > Varsha
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Kaboodle-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
> >
>
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel