Hank Oredson wrote:

"Peter Lemken" wrote in message

Yes, there is, Hank. API stands for "Advanced Programming Interface" and it
describes the programming interface to a lower layer that you can use.

"Application programming interface."
"... TO THE DATABASE."

The Central Database of the arrl lotw project?

The API is right there, it's documented, it's usable.

There is NO API TO THE DATABASE.

I am still not sure you are talking about the database I had in mind.

This should be very very simple to understand.
What you show me is a set of library calls for manipulating
LOCAL DATA and LOCAL FILES. This is not of interest.

Yes, it is, at least for log programmers. Prepare the data in an accepted
form, sign it digitally with your unique key and hold personal
responsibility for the integrity of the data. And that is done locally by a
log program. Am I still with you?

Obviously, what you are looking for is an _application_ that performs
certain tasks to your liking. That's not what an API does, you need to write
an application that makes use of the API.

I am not looking for an application.
I WRITE APPLICATIONS.

What kind of applications? Logbooks?

To do this, I NEED THE SPECIFICATION.
IF I have the specification ... see below ...

Apart from that: This is an Open Source project, so you can contribute your
patches and express dissatisfaction with what's currently available.

There is NOTHING available.
There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE.
None, zero, nichts, nada.
Were there such a specification, I would CREATE a library of
functions and gladly donate it to the project. Then there would
be an API to the DATABASE, and everyone could use it.

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

What you want is restricted remote access to another machine in order to
manipulate data (QSO-records). Have I understood you correctly?

For eQSL, I can do these things.
There is an API, it is documented.

LotW is still in it's baby steps, perhaps like a very early prototype.

I'm gonna refer to that once you tell me whether I have understood you
correctly about the central database of the ARRL.

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:

"Peter Lemken" wrote in message

Yes, there is, Hank. API stands for "Advanced Programming Interface" and
it
describes the programming interface to a lower layer that you can use.

"Application programming interface."
"... TO THE DATABASE."

The Central Database of the arrl lotw project?

Yes.

The API is right there, it's documented, it's usable.

There is NO API TO THE DATABASE.

I am still not sure you are talking about the database I had in mind.

This should be very very simple to understand.
What you show me is a set of library calls for manipulating
LOCAL DATA and LOCAL FILES. This is not of interest.

Yes, it is, at least for log programmers. Prepare the data in an accepted
form, sign it digitally with your unique key and hold personal
responsibility for the integrity of the data. And that is done locally by a
log program. Am I still with you?

Yes.

Obviously, what you are looking for is an _application_ that performs
certain tasks to your liking. That's not what an API does, you need to
write
an application that makes use of the API.

I am not looking for an application.
I WRITE APPLICATIONS.

What kind of applications? Logbooks?

Logbook and log archive are of interest here of course.
What kind of applications do I write? Many ;-)

To do this, I NEED THE SPECIFICATION.
IF I have the specification ... see below ...

Apart from that: This is an Open Source project, so you can contribute
your
patches and express dissatisfaction with what's currently available.

There is NOTHING available.
There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE.
None, zero, nichts, nada.
Were there such a specification, I would CREATE a library of
functions and gladly donate it to the project. Then there would
be an API to the DATABASE, and everyone could use it.

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

What you want is restricted remote access to another machine in order to
manipulate data (QSO-records). Have I understood you correctly?

Yes. Exactly.
Realtime access to the database.
With the same security as any other access, via certificate and signing.

For eQSL, I can do these things.
There is an API, it is documented.

LotW is still in it's baby steps, perhaps like a very early prototype.

I'm gonna refer to that once you tell me whether I have understood you
correctly about the central database of the ARRL.

Yes, the one and only LotW database. Where the QSO and QSL
information is located. Online access to that database.

Right now access is via file upload (or email) to put data INTO
the database, and is via HTTP to get data OUT of the database.
I could reverse engineer that process and use it. But it seems better
to have a documented and supported API.

As I mentioned before, this API might be ONLY a protocol
specification, with NO code (libraries) involved.

What I'm talking about is different than the issue of signing the
data. That is already handled by the tQSL library. I don't like
the way the library is organized (too low level and complex),
but that is not a problem since I can put my own wrapper on
top of what exists to make reasonable functions.

Mostly I discuss these ideas because I think it is important for
LotW to do much much more than it does now. If it does not,
people will not integrate it into their applications, it will not be
used, and the project will fail. The existing prototype of LotW
does not seem to me very useful. Perhaps that will change.

There are other competing "global ham radio QSO" databases.
Eventually these databases will need to be linked for them to
be useful. It is not clear that LotW has a chance. Were the LotW
team work with others (e.g. eQSL) progress might occur faster.

I step down from my soapbox now.

Sorry for delay in this response, took a few minutes away from
the computer to work 3C0V on 15M ...


--

... Hank

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

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

"Peter Lemken" wrote in message

Yes, there is, Hank. API stands for "Advanced Programming Interface" and
it
describes the programming interface to a lower layer that you can use.

"Application programming interface."
"... TO THE DATABASE."

The Central Database of the arrl lotw project?

Yes.

The API is right there, it's documented, it's usable.

There is NO API TO THE DATABASE.

I am still not sure you are talking about the database I had in mind.

This should be very very simple to understand.
What you show me is a set of library calls for manipulating
LOCAL DATA and LOCAL FILES. This is not of interest.

Yes, it is, at least for log programmers. Prepare the data in an accepted
form, sign it digitally with your unique key and hold personal
responsibility for the integrity of the data. And that is done locally by a
log program. Am I still with you?

Yes.

Obviously, what you are looking for is an _application_ that performs
certain tasks to your liking. That's not what an API does, you need to
write
an application that makes use of the API.

I am not looking for an application.
I WRITE APPLICATIONS.

What kind of applications? Logbooks?

Logbook and log archive are of interest here of course.
What kind of applications do I write? Many ;-)

To do this, I NEED THE SPECIFICATION.
IF I have the specification ... see below ...

Apart from that: This is an Open Source project, so you can contribute
your
patches and express dissatisfaction with what's currently available.

There is NOTHING available.
There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE.
None, zero, nichts, nada.
Were there such a specification, I would CREATE a library of
functions and gladly donate it to the project. Then there would
be an API to the DATABASE, and everyone could use it.

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

What you want is restricted remote access to another machine in order to
manipulate data (QSO-records). Have I understood you correctly?

Yes. Exactly.
Realtime access to the database.
With the same security as any other access, via certificate and signing.

For eQSL, I can do these things.
There is an API, it is documented.

LotW is still in it's baby steps, perhaps like a very early prototype.

I'm gonna refer to that once you tell me whether I have understood you
correctly about the central database of the ARRL.

Yes, the one and only LotW database. Where the QSO and QSL
information is located. Online access to that database.

Right now access is via file upload (or email) to put data INTO
the database, and is via HTTP to get data OUT of the database.
I could reverse engineer that process and use it. But it seems better
to have a documented and supported API.

As I mentioned before, this API might be ONLY a protocol
specification, with NO code (libraries) involved.

What I'm talking about is different than the issue of signing the
data. That is already handled by the tQSL library. I don't like
the way the library is organized (too low level and complex),
but that is not a problem since I can put my own wrapper on
top of what exists to make reasonable functions.

Mostly I discuss these ideas because I think it is important for
LotW to do much much more than it does now. If it does not,
people will not integrate it into their applications, it will not be
used, and the project will fail. The existing prototype of LotW
does not seem to me very useful. Perhaps that will change.

There are other competing "global ham radio QSO" databases.
Eventually these databases will need to be linked for them to
be useful. It is not clear that LotW has a chance. Were the LotW
team work with others (e.g. eQSL) progress might occur faster.

I step down from my soapbox now.

Sorry for delay in this response, took a few minutes away from
the computer to work 3C0V on 15M ...


--

... Hank

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

Just to make Hank's point concrete:

One can today export ADIF from a logging application and upload that ADIF to
LOTW. However, it is not possible to write an application that can determine
which of the QSOs in that uploaded ADIF were accepted by LOTW (as opposed to
rejected for a host of possible reasons). Furthermore, it is not possible to
write an application that can determine which of the QSOs accepted by LOTW
have been "matched" by LOTW and thus considered confirmed. If a user wishes
his or her logging application to accurately reflect the status shown on the
LOTW web page, that user must manually update the logging application, QSO
by QSO.

This situation exists because there is no documented API that provides
access to information in the LOTW database. The access required is
read-only; the fact that the database is centralized is not an obstacle to
the provision of a client API.

I have discussed these points months ago with Jon KE3Z (LOTW project
manager) on the Trusted QSL reflector, and he acknowledged an intent to
provide such a mechanism; the relevant messages are
http://groups.yahoo.com/group/TrustedQSL/message/240 and
http://groups.yahoo.com/group/TrustedQSL/message/246 . My understanding is
that the LOTW team has higher priorities right now.

In my view, an API should have been provided prior to beta test; waiting
until after production release to implement such functionality is highly
risky. That, however, is where we are. Lets just hope this functionality
isn't permanently triaged. Pressure from the user community wouldn't hurt.

73,

Dave, AA6YQ

"Hank Oredson" wrote in message
...

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

"Peter Lemken" wrote in message

Yes, there is, Hank. API stands for "Advanced Programming Interface"
and
it
describes the programming interface to a lower layer that you can
use.

"Application programming interface."
"... TO THE DATABASE."

The Central Database of the arrl lotw project?

Yes.

The API is right there, it's documented, it's usable.

There is NO API TO THE DATABASE.

I am still not sure you are talking about the database I had in mind.

This should be very very simple to understand.
What you show me is a set of library calls for manipulating
LOCAL DATA and LOCAL FILES. This is not of interest.

Yes, it is, at least for log programmers. Prepare the data in an
accepted
form, sign it digitally with your unique key and hold personal
responsibility for the integrity of the data. And that is done locally
by a
log program. Am I still with you?

Yes.

Obviously, what you are looking for is an _application_ that
performs
certain tasks to your liking. That's not what an API does, you need
to
write
an application that makes use of the API.

I am not looking for an application.
I WRITE APPLICATIONS.

What kind of applications? Logbooks?

Logbook and log archive are of interest here of course.
What kind of applications do I write? Many ;-)

To do this, I NEED THE SPECIFICATION.
IF I have the specification ... see below ...

Apart from that: This is an Open Source project, so you can
contribute
your
patches and express dissatisfaction with what's currently available.

There is NOTHING available.
There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE.
None, zero, nichts, nada.
Were there such a specification, I would CREATE a library of
functions and gladly donate it to the project. Then there would
be an API to the DATABASE, and everyone could use it.

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

What you want is restricted remote access to another machine in order to
manipulate data (QSO-records). Have I understood you correctly?

Yes. Exactly.
Realtime access to the database.
With the same security as any other access, via certificate and signing.

For eQSL, I can do these things.
There is an API, it is documented.

LotW is still in it's baby steps, perhaps like a very early prototype.

I'm gonna refer to that once you tell me whether I have understood you
correctly about the central database of the ARRL.

Yes, the one and only LotW database. Where the QSO and QSL
information is located. Online access to that database.

Right now access is via file upload (or email) to put data INTO
the database, and is via HTTP to get data OUT of the database.
I could reverse engineer that process and use it. But it seems better
to have a documented and supported API.

As I mentioned before, this API might be ONLY a protocol
specification, with NO code (libraries) involved.

What I'm talking about is different than the issue of signing the
data. That is already handled by the tQSL library. I don't like
the way the library is organized (too low level and complex),
but that is not a problem since I can put my own wrapper on
top of what exists to make reasonable functions.

Mostly I discuss these ideas because I think it is important for
LotW to do much much more than it does now. If it does not,
people will not integrate it into their applications, it will not be
used, and the project will fail. The existing prototype of LotW
does not seem to me very useful. Perhaps that will change.

There are other competing "global ham radio QSO" databases.
Eventually these databases will need to be linked for them to
be useful. It is not clear that LotW has a chance. Were the LotW
team work with others (e.g. eQSL) progress might occur faster.

I step down from my soapbox now.

Sorry for delay in this response, took a few minutes away from
the computer to work 3C0V on 15M ...


--

... Hank

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

Just to make Hank's point concrete:

One can today export ADIF from a logging application and upload that ADIF to
LOTW. However, it is not possible to write an application that can determine
which of the QSOs in that uploaded ADIF were accepted by LOTW (as opposed to
rejected for a host of possible reasons). Furthermore, it is not possible to
write an application that can determine which of the QSOs accepted by LOTW
have been "matched" by LOTW and thus considered confirmed. If a user wishes
his or her logging application to accurately reflect the status shown on the
LOTW web page, that user must manually update the logging application, QSO
by QSO.

This situation exists because there is no documented API that provides
access to information in the LOTW database. The access required is
read-only; the fact that the database is centralized is not an obstacle to
the provision of a client API.

I have discussed these points months ago with Jon KE3Z (LOTW project
manager) on the Trusted QSL reflector, and he acknowledged an intent to
provide such a mechanism; the relevant messages are
http://groups.yahoo.com/group/TrustedQSL/message/240 and
http://groups.yahoo.com/group/TrustedQSL/message/246 . My understanding is
that the LOTW team has higher priorities right now.

In my view, an API should have been provided prior to beta test; waiting
until after production release to implement such functionality is highly
risky. That, however, is where we are. Lets just hope this functionality
isn't permanently triaged. Pressure from the user community wouldn't hurt.

73,

Dave, AA6YQ

"Hank Oredson" wrote in message
...

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

"Peter Lemken" wrote in message

Yes, there is, Hank. API stands for "Advanced Programming Interface"
and
it
describes the programming interface to a lower layer that you can
use.

"Application programming interface."
"... TO THE DATABASE."

The Central Database of the arrl lotw project?

Yes.

The API is right there, it's documented, it's usable.

There is NO API TO THE DATABASE.

I am still not sure you are talking about the database I had in mind.

This should be very very simple to understand.
What you show me is a set of library calls for manipulating
LOCAL DATA and LOCAL FILES. This is not of interest.

Yes, it is, at least for log programmers. Prepare the data in an
accepted
form, sign it digitally with your unique key and hold personal
responsibility for the integrity of the data. And that is done locally
by a
log program. Am I still with you?

Yes.

Obviously, what you are looking for is an _application_ that
performs
certain tasks to your liking. That's not what an API does, you need
to
write
an application that makes use of the API.

I am not looking for an application.
I WRITE APPLICATIONS.

What kind of applications? Logbooks?

Logbook and log archive are of interest here of course.
What kind of applications do I write? Many ;-)

To do this, I NEED THE SPECIFICATION.
IF I have the specification ... see below ...

Apart from that: This is an Open Source project, so you can
contribute
your
patches and express dissatisfaction with what's currently available.

There is NOTHING available.
There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE.
None, zero, nichts, nada.
Were there such a specification, I would CREATE a library of
functions and gladly donate it to the project. Then there would
be an API to the DATABASE, and everyone could use it.

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

What you want is restricted remote access to another machine in order to
manipulate data (QSO-records). Have I understood you correctly?

Yes. Exactly.
Realtime access to the database.
With the same security as any other access, via certificate and signing.

For eQSL, I can do these things.
There is an API, it is documented.

LotW is still in it's baby steps, perhaps like a very early prototype.

I'm gonna refer to that once you tell me whether I have understood you
correctly about the central database of the ARRL.

Yes, the one and only LotW database. Where the QSO and QSL
information is located. Online access to that database.

Right now access is via file upload (or email) to put data INTO
the database, and is via HTTP to get data OUT of the database.
I could reverse engineer that process and use it. But it seems better
to have a documented and supported API.

As I mentioned before, this API might be ONLY a protocol
specification, with NO code (libraries) involved.

What I'm talking about is different than the issue of signing the
data. That is already handled by the tQSL library. I don't like
the way the library is organized (too low level and complex),
but that is not a problem since I can put my own wrapper on
top of what exists to make reasonable functions.

Mostly I discuss these ideas because I think it is important for
LotW to do much much more than it does now. If it does not,
people will not integrate it into their applications, it will not be
used, and the project will fail. The existing prototype of LotW
does not seem to me very useful. Perhaps that will change.

There are other competing "global ham radio QSO" databases.
Eventually these databases will need to be linked for them to
be useful. It is not clear that LotW has a chance. Were the LotW
team work with others (e.g. eQSL) progress might occur faster.

I step down from my soapbox now.

Sorry for delay in this response, took a few minutes away from
the computer to work 3C0V on 15M ...


--

... Hank

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

On Fri, 03 Oct 2003 22:01:53 GMT, "Hank Oredson"
wrote:

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

You can't do that unless your ISP has DSL modems with a quarter
slot in the top......

Not to mention it wouldn't be "secure" if you knew who I worked.
Maybe I worked you and you didn't know it, so you could then
apply for credit for working me even though you didn't know you
did. (work me)

LOTW is much more complicated that it really appears to be.....

Please try very hard to understand what the ARRL has written.
Software for collecting quarters...... Cha Ching.......

73, Jim KH2D

On Fri, 03 Oct 2003 22:01:53 GMT, "Hank Oredson"
wrote:

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

You can't do that unless your ISP has DSL modems with a quarter
slot in the top......

Not to mention it wouldn't be "secure" if you knew who I worked.
Maybe I worked you and you didn't know it, so you could then
apply for credit for working me even though you didn't know you
did. (work me)

LOTW is much more complicated that it really appears to be.....

Please try very hard to understand what the ARRL has written.
Software for collecting quarters...... Cha Ching.......

73, Jim KH2D

wrote in message
.. .
On Fri, 03 Oct 2003 22:01:53 GMT, "Hank Oredson"
wrote:

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

You can't do that unless your ISP has DSL modems with a quarter
slot in the top......

Why? I can access my QSO data via the web page for no charge.

Not to mention it wouldn't be "secure" if you knew who I worked.

Why? I can only access my own QSO data.

Maybe I worked you and you didn't know it, so you could then
apply for credit for working me even though you didn't know you
did. (work me)

For this part of the discussion, and for the API of interest,
awards do not come into play. Only my own QSO data.

LOTW is much more complicated that it really appears to be.....

Naw, I think it is less complex than it appears :-)

Please try very hard to understand what the ARRL has written.

Oh I do understand!

Software for collecting quarters...... Cha Ching.......

That is the ARRL view of their database.
My view is different, since I do not care about the awards.

--

... Hank

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

wrote in message
.. .
On Fri, 03 Oct 2003 22:01:53 GMT, "Hank Oredson"
wrote:

Please try very very hard to understand what I have written.
LotW is a CENTRALIZED DATABASE of QSO data.
I wish to access it.
From applications I will write.

You can't do that unless your ISP has DSL modems with a quarter
slot in the top......

Why? I can access my QSO data via the web page for no charge.

Not to mention it wouldn't be "secure" if you knew who I worked.

Why? I can only access my own QSO data.

Maybe I worked you and you didn't know it, so you could then
apply for credit for working me even though you didn't know you
did. (work me)

For this part of the discussion, and for the API of interest,
awards do not come into play. Only my own QSO data.

LOTW is much more complicated that it really appears to be.....

Naw, I think it is less complex than it appears :-)

Please try very hard to understand what the ARRL has written.

Oh I do understand!

Software for collecting quarters...... Cha Ching.......

That is the ARRL view of their database.
My view is different, since I do not care about the awards.

--

... Hank

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