Hi! This is the last email I will answer before going out for holidays so next 2 weeks I will be a little quiet :) El dom, 15-08-2004 a las 00:01, Richard Hult escribió: > On lör, 2004-08-14 at 06:00 +0200, Alvaro del Castillo wrote: > > > > We probably need to have a way to identity a certain e-d-s instance and > > > never sync unless it's the right one (possibly with special casing for > > > the ldap case, if possible). > > > > > > > The e-d-s instance has a unique identifier. This identifier is link to > > the machine where it was generated and also, has a unique serial number. > > So this is the way to identify a e-d-s instance. > > > > In Planner, take a look to 621 line change in he right column: > > > > http://cvs.gnome.org/viewcvs/planner/src/planner-eds-plugin.c?r1=1.3&r2=1.4 > > > > And this is how UIDs are generated: > > > > http://cvs.gnome.org/viewcvs/evolution-data-server/libedataserver/e-uid.c?rev=1.2&view=auto > > (e_uid_new) > > Hm, this doesn't solve the situation I was talking about, does it? > Hmmm, it is in the line: << We probably need to have a way to identity a certain e-d-s instance>> uids for resource in e-d-s is what we have right now. When we access e-d-s resources, is the way it has to identify the resources. But yes, it has problems as you show ... > First, lots of computers are named localhost => not unique. And also if > two users on the same machine exchanges files, they can have the same > ID. Ok, this is one field in the ID. > > On the other hand, the generated ID is probably "unique enough" for this > to work. But it's not a very nice solution, in my opinion. > So we need a better solution but until we have it the normal case will be a user importing from evolution resources and with the actual code, we can warranty that if a resource have been already imported, it wouldn't be imported another time. I think the best thing we can do is start thinking about the scenarios we want to support and find solutions for them. > > Actually, only when importing resources that have the same uid that one > > that exists in planner, the update of the resource in planner is done. > > So if you send me a file and I import some resources from evolution, it > > is impossible to update your resources with my resources if they are > > local. > > It's not impossible. It's possible that we happen to have the same id > for two different contacts in our e-d-s. The probability for it to > happen might be sufficently slim though. I haven't thought a lot for the distributed case but yes, there is a probability that we share some uids. I don't have lots of experience creating ids that are unique not only in one machine, but also between different machines. Maybe we can use the ethernet mac or things like that but I think this kinds of things need to be solved at e-d-s level. > > > If they come from a ldap, I have to take a look af the uid > > generation because I feel they will be shared so updates will occur, and > > I think this is what we want. > > That would work fine. > > If we can check that the e-d-s instance is the same, we can sync > automatically, or if it's ldap, we can sync automatically always. > Yes, when I return I continue working on those things and if so nice ideas appear to solve the uniqueness of the uids, we can make them real :) Cheers -- Alvaro > /Richard
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente