A pile of code is not an API, its a pile of code. An API is a designated,
documented interface designed to be stable (in an upwardly-compatible way)
over time so that client applications can interact reliably.

I'm beginning to think you weren't joking.

73,

Dave, AA6YQ

"Peter Lemken" wrote in message
...
Hank Oredson wrote:

3rd hit. Already have that document.
No API specification in that document.

OK, Hank, you seem to need spoonfeeding:

http://www.trustedqsl.org/

Not very obvious and *very* hard to find. But it has an FAQ.

http://cesnet.dl.sourceforge.net/sou...qsllib-doc.zip

That's on Sourceforge. You *did* look there, didn't you?

Peter Lemken
DF5JT
Berlin

--
Mail an die im From: angegebene Adresse stellt eine Beauftragung zur
Überprüfung der Mailfunktion des Absenders dar und wird mit einer
Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt.

Hank Oredson wrote:

I am aware of the architecture, understand how the certificates
are used, have my own database and software for dealing with
logs, station identification, DX entities, have ADIF
reading and writing functions for that database, etc.

What I have not yet found is the API into the LotW database, so that I
can create my own client to view, modify, delete and insert QSO data.

Something like that?

|Detailed Description
|The Data API is used to form data into TrustedQSL
|records. A TrustedQSL record consists of a station record and a QSO
|record. Together, the two records fully describe one station's end of the
|QSO -- just as a paper QSL card does.

I believe this describes the local part of want you want to do with your
QSO-data: Forming records, converting and modifying these records and then
upload them via the tqsllib.

Have I understood you correctly this time?

Peter Lemken
DF5JT
Berlin

--
Mail an die im From: angegebene Adresse stellt eine Beauftragung zur
Überprüfung der Mailfunktion des Absenders dar und wird mit einer
Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt.

Hank Oredson wrote:

I am aware of the architecture, understand how the certificates
are used, have my own database and software for dealing with
logs, station identification, DX entities, have ADIF
reading and writing functions for that database, etc.

What I have not yet found is the API into the LotW database, so that I
can create my own client to view, modify, delete and insert QSO data.

Something like that?

|Detailed Description
|The Data API is used to form data into TrustedQSL
|records. A TrustedQSL record consists of a station record and a QSO
|record. Together, the two records fully describe one station's end of the
|QSO -- just as a paper QSL card does.

I believe this describes the local part of want you want to do with your
QSO-data: Forming records, converting and modifying these records and then
upload them via the tqsllib.

Have I understood you correctly this time?

Peter Lemken
DF5JT
Berlin

--
Mail an die im From: angegebene Adresse stellt eine Beauftragung zur
Überprüfung der Mailfunktion des Absenders dar und wird mit einer
Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt.

"Peter Lemken" wrote in message
...
Hank Oredson wrote:

I am aware of the architecture, understand how the certificates
are used, have my own database and software for dealing with
logs, station identification, DX entities, have ADIF
reading and writing functions for that database, etc.

What I have not yet found is the API into the LotW database, so that I
can create my own client to view, modify, delete and insert QSO data.

Something like that?

|Detailed Description
|The Data API is used to form data into TrustedQSL
|records. A TrustedQSL record consists of a station record and a QSO
|record. Together, the two records fully describe one station's end of the
|QSO -- just as a paper QSL card does.

I believe this describes the local part of want you want to do with your
QSO-data: Forming records, converting and modifying these records and then
upload them via the tqsllib.

Have I understood you correctly this time?


Getting closer :-)

Here is a description of one application.

1. Connect to the server.
This would probably be via HTTP with a cookie to create a session.

2. Authenticate myself to the server.
Using my user name and password, and possibly a certificate.

3. Query the server for one or more QSO records.
Something that looks like SQL would be most convenient.
It should be possible to say "read only" or "for modification".

4. Acquire the records returned by the query.
The server must also return status information for each record.

5. View and modify the records locally. Possibly create new records.

6. Return any modified or new records to the server.

7. Acquire status information from the server.

8. Disconnect from the server.

I want operations on records, not fields.
Things like "tqsl_getLocationDXCCEntity" are simply too low level.

What I do not see in tqsllib are the "open database", "get record",
"put record", "close database" functions that are needed to build an
application. We will see how things work out over time. Perhaps
everything I want is actually there, hidden under that huge pile of
low level internal function calls.

--

... Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net

"Peter Lemken" wrote in message
...
Hank Oredson wrote:

I am aware of the architecture, understand how the certificates
are used, have my own database and software for dealing with
logs, station identification, DX entities, have ADIF
reading and writing functions for that database, etc.

What I have not yet found is the API into the LotW database, so that I
can create my own client to view, modify, delete and insert QSO data.

Something like that?

|Detailed Description
|The Data API is used to form data into TrustedQSL
|records. A TrustedQSL record consists of a station record and a QSO
|record. Together, the two records fully describe one station's end of the
|QSO -- just as a paper QSL card does.

I believe this describes the local part of want you want to do with your
QSO-data: Forming records, converting and modifying these records and then
upload them via the tqsllib.

Have I understood you correctly this time?


Getting closer :-)

Here is a description of one application.

1. Connect to the server.
This would probably be via HTTP with a cookie to create a session.

2. Authenticate myself to the server.
Using my user name and password, and possibly a certificate.

3. Query the server for one or more QSO records.
Something that looks like SQL would be most convenient.
It should be possible to say "read only" or "for modification".

4. Acquire the records returned by the query.
The server must also return status information for each record.

5. View and modify the records locally. Possibly create new records.

6. Return any modified or new records to the server.

7. Acquire status information from the server.

8. Disconnect from the server.

I want operations on records, not fields.
Things like "tqsl_getLocationDXCCEntity" are simply too low level.

What I do not see in tqsllib are the "open database", "get record",
"put record", "close database" functions that are needed to build an
application. We will see how things work out over time. Perhaps
everything I want is actually there, hidden under that huge pile of
low level internal function calls.

--

... Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net

Hank Oredson wrote:

I want operations on records, not fields.
Things like "tqsl_getLocationDXCCEntity" are simply too low level.

Then an API is not what you are looking for, methinks.

Peter Lemken
DF5JT
Berlin

--
Mail an die im From: angegebene Adresse stellt eine Beauftragung zur
Überprüfung der Mailfunktion des Absenders dar und wird mit einer
Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt.

Hank Oredson wrote:

I want operations on records, not fields.
Things like "tqsl_getLocationDXCCEntity" are simply too low level.

Then an API is not what you are looking for, methinks.

Peter Lemken
DF5JT
Berlin

--
Mail an die im From: angegebene Adresse stellt eine Beauftragung zur
Überprüfung der Mailfunktion des Absenders dar und wird mit einer
Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt.

On 1 Oct 2003 16:38:48 GMT, Peter Lemken wrote:
Hank Oredson wrote:

I want operations on records, not fields.
Things like "tqsl_getLocationDXCCEntity" are simply too low level.

Then an API is not what you are looking for, methinks.

Peter Lemken
DF5JT
Berlin


- been following this thread...

- the ultimate documentation for an application?

- the source code!

--
Mail an die im From: angegebene Adresse stellt eine Beauftragung zur
Überprüfung der Mailfunktion des Absenders dar und wird mit einer
Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt.

On 1 Oct 2003 16:38:48 GMT, Peter Lemken wrote:
Hank Oredson wrote:

I want operations on records, not fields.
Things like "tqsl_getLocationDXCCEntity" are simply too low level.

Then an API is not what you are looking for, methinks.

Peter Lemken
DF5JT
Berlin


- been following this thread...

- the ultimate documentation for an application?

- the source code!

--
Mail an die im From: angegebene Adresse stellt eine Beauftragung zur
Überprüfung der Mailfunktion des Absenders dar und wird mit einer
Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt.

wrote in message
...
On 1 Oct 2003 16:38:48 GMT, Peter Lemken wrote:
Hank Oredson wrote:

I want operations on records, not fields.
Things like "tqsl_getLocationDXCCEntity" are simply too low level.

Then an API is not what you are looking for, methinks.

Peter Lemken
DF5JT
Berlin


- been following this thread...

- the ultimate documentation for an application?

There is NO such application.

- the source code!

Pretty hard to look at source code that does not exist.

--

... Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net