X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0~rc1-2) with nmh-1.5
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: karl AT aspodata DOT se
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] identical symbol names
In-reply-to: <CAG4ve9KgoDkkXivoBGL8C2nwToNWjG_Zo61+XeR=sQNeSAnPow@mail.gmail.com>
References: <CAG4ve9LgHNoVZoGaGgF67tadJ_n=L6Uy1g=UPPrkM0fL6Rgufw AT mail DOT gmail DOT com> <20140127234944 DOT 924148045B78 AT turkos DOT aspodata DOT se> <CAG4ve9+3jhFJ1Cr6CLUyLX_y02uigJECiUCwxjUWdP=heVocqg AT mail DOT gmail DOT com> <20140128201110 DOT DF7D78045B78 AT turkos DOT aspodata DOT se> <20140129072550 DOT GA24560 AT localhost DOT localdomain> <CAG4ve9+v9QxNRaPSFkmGfr6bKsv7km-Gt_gwXF7Eh4TX+AmNug AT mail DOT gmail DOT com> <CAOP4iL2JBUdF93kZF-iQ9Rv+VTN3iXoT+6C4LoBi5qaMxof=sA AT mail DOT gmail DOT com> <CAG4ve9+QsUf=nVXPe-f3VddGiqHn8sjZUJNkdu3QV1cOQDWiAg AT mail DOT gmail DOT com> <86CABBE6-EE80-4347-B7AA-3F5A8DA4C658 AT noqsi DOT com> <CAG4ve9LX0mYk2a1zpfWJJC=OP5Weq9pt3PF7_Nqx5vX4wpR=Bg AT mail DOT gmail DOT com> <1394402434 DOT 2151 DOT 28 DOT camel AT AMD64X2 DOT fritz DOT box> <CAG4ve9KgoDkkXivoBGL8C2nwToNWjG_Zo61+XeR=sQNeSAnPow AT mail DOT gmail DOT com>
Comments: In-reply-to =?KOI8-R?B?4czFy9PFyiDowdLYy8/X08vJyg==?= <svetonomer AT gmail DOT com>
   message dated "Tue, 11 Mar 2014 04:29:09 +0400."
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Message-Id: <20140311130801.94D928020170@turkos.aspodata.se>
Date: Tue, 11 Mar 2014 14:07:59 +0100 (CET)
X-Virus-Scanned: ClamAV using ClamSMTP
Note-from-DJ: This may be spam
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Алексей Харьковский:
> Stefan Salewski:
> > Assume you have a symbol which includes a link to a PDF Datasheet.
> > The link may change.
> Yes.  Offensively.

You could solve that with a local cache or finding some archive on the 
net.

For a local cache of e.g. pdf's you could use

 wget --no-check-certificate -x -N -c --protocol-directories <URL>

in "your local cache" directory. Though that doesn't help when people are
hiding the files behind javascript.

> Assume you have a symbol which was included in many your schemas from CVS.
> Example capacitor or other usable for you.
> Througth time autor change pin length and make this less.
> All schemas in you archive is broken.

You can solve this example noting the version you used and include it 
somewhere so people can exstract the same version from cvs. A checksum 
could be provided as an extra check.

> Yes, they can generate trouble:
> > 1. When you have an untrusted source
> 
> Yes. Example gedasymbols.

(I wouldn't call gedasymbols an "untrusted" source, it's more of a 
"remote" source that you yourself don't have control over.)

> > (for this problem you should make a
> > local backup copy.)
> >
> If insert symbol from local copy to schemas always, how to detect source
> change. Before placing perform diff command?

If you always are using your own copy, you are not bothered by source 
changes. If you have a specific sym you are interested in you can check 
the changes manually.

> If insert from changeable, and make backup after, this similar my propose.

I don't understand your english here.

> > 2. When there exist different sources with the same name. For this case
> > you can insert more data into the symbol, i.e. authors name and version
> > number.
> >
> That is, all versions must be kept, even when they are outdated....
> That is, project developers must have a centralized repository of
> characters.

You don't need a "centralized" repository, you need some kind of 
version control, and it is a good investment to use one.

...
> > Long time ago I suggested that gschem should store a checksum for each
> > referenced symbol, so changes of that symbol can be detected. I still
> > think that that is a good idea. Further gschem could save some fields,
> > i.e. author and version. So if it becomes unclear which symbol the
> > schematic is referencing, there is some information available to decide.
> I open file from gschem. Gschem sees that the checksum is incorrect.
> What gschem should make?

Check if you have a disk related problem, are your file currupt,
contact the author of the symbol, etc.

A checksum is a check that "all are in order". The procedure to handle 
any mismatch is not solved by using a checksum, but it helps to _detect_
possible problems.

> > I agree that for some cases copies of symbols are preferable. Some
> > people like self-contained documents
> 
> Self-contained documents more relaible versus referable.
> Reliability that you should strive.
> Reliability are not redundant.

So your case for the "in the file library" solution is:

1, solve same name problem
2, get some reliability against sym file changes

> In some cases, it more conveniently.
> Imagine I want to send the scheme to another developer to edit or cut of
> part of this or simple view.
> I send him a circuit file and say: this symbol take from Stefan, this from
> Karl, at this from DJ Delorie, and the rest from I send in archive.
> :)))

3, and distribution

Am I right?

1 and 2 could be solved by including author/vendor and version 
information.

3 can be solved by making the your repo. public or by having some 
"collect and distribute" script.

And yes, implementing thoose things, so your solution have a head
start, but others can catch up. The most interesting thing right now
is to identify problem areas of gschem sym file handling, proposing
different solutions, and sharing experiences. Implementation comes
later. You have a solution and an implementation, and that is a
very good starting point when trying to nail down a problem and
for discussions.

///

Problem areas are (as I understand):

. same sym file name problem
. cvs.gedasymbols.org, your own git/hg/... repo. sym file changes
. distribution of scheme files (so all symbols show up correct)
. remote sources of sym files (netw., connectivity, local caches)

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57