SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 12:37 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 14:01 UTC)
|
Re: SRFI 198 and the Schemeregistry hga@xxxxxx (30 Aug 2020 14:25 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 14:52 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 15:45 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 16:06 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 14:55 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 15:22 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 16:05 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 16:39 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 16:56 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 20:13 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 15:23 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 15:35 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 15:44 UTC)
|
Re: SRFI 198 and the Schemeregistry
Marc Nieper-Wißkirchen
(30 Aug 2020 16:02 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 17:05 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 17:47 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 18:56 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 18:59 UTC)
|
Re: SRFI 198 and the Schemeregistry
Marc Nieper-Wißkirchen
(30 Aug 2020 19:45 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 17:34 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 17:55 UTC)
|
Re: SRFI 198 and the Schemeregistry
Arthur A. Gleckler
(30 Aug 2020 18:27 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 18:57 UTC)
|
Re: SRFI 198 and the Schemeregistry
Arthur A. Gleckler
(30 Aug 2020 19:10 UTC)
|
Don't panic
Lassi Kortela
(30 Aug 2020 19:28 UTC)
|
Re: Don't panic
Marc Nieper-Wißkirchen
(30 Aug 2020 19:34 UTC)
|
Re: Don't panic
Arthur A. Gleckler
(30 Aug 2020 20:00 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 19:57 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 20:09 UTC)
|
> From: Lassi Kortela <xxxxxx@lassi.io> > Date: Sunday, August 30, 2020 9:01 AM > > Thanks for getting back to this. That's a good summary. You're welcome, and I'm glad I communicated your vision with a degree of accuracy. >> So I ask, in Lassi's vision of SRFI 198, how would an author of an >> Oracle interface easily and with the least friction discover on >> registry.scheme.org that there is a 'sqlstate convention, and the >> multiple sub-conventions "under" 'sqlstate. > > I would do something like this: > > (make-foreign-status > 'set 'oracle-ORA > 'code 12154 > 'sqlstate "08004" > 'message "TNS could not resolve service name") > > [...] > > These rely on the fact that some property names only make sense with > particular foreign interfaces. 'oracle-ORA only makes sense with Oracle.... > > Likewise, 'sqlstate only makes sense with SQL databases; if you FIND it.... Emphasis added to "find". And I'm sorry I failed to communicate my question. *Exactly* how would the library developer consulting registry.scheme.org discover "'sqlstate" and "'oracle-ORA"? Would he navigate to a sub-page and ^F/F3 search for likely things, like "database", "RDMBS", "sql", etc.? If there is such a sub-page, what limiting principle, if any, would be used to decide which names to include in it, vs. ones that might be in a sub-sub-page like fiddly details only relevant to Oracle ORAs, PostgreSQL status returns, etc.? > [ More good arguments for his position. ] - Harold