Re: Log Program for Linux

From: gsuga.qokmd@mail.dy.fi
Date: Tue May 16 2000 - 08:13:01 EEST

  • Next message: Piotr Stempniak: "SCC, kernel 2.2.13 and Slackware 7.0"

    > On Thu, 11 May 2000, Hamish Moffatt wrote:
    > >
    > > At the same time, we've agreed that no single front end will suffice
    > > for both contesting and casual QSOs. So since we accept that multiple
    > > front ends can be needed, they can differ in implementation too. I don't
    > > think a web front end could be fast enough or flexible enough for
    > > contesting.
    >
    > Well, how long lasts a Contest QSO in seconds? 5 secs?

    No idea. I am newbie on radio and all that.

    > Prabably you
    > still have speed to use a Web FrontEnd.
    > The big problem in an Web Frontend is that we have to "Confirm" the data
    > in the form, and it is not pratical to use a mouse to do it.

    If you mean with that that you have to point on the submit button with the
    mouse pointer, that's not a problem. There are alternatives, and using the
    return key to do it is to me one of the best choices.

    > This is the
    > only problem I see. Maybe there is a turn around to this problem.

    There is a turn around, so that's not a problem.

    > For normal DXeing I see other problem that I trying to solve. When you
    > write a callsign, normally you want see, right after, what is operator's
    > name, the QSOs already done with him, etc. As we have to "submit" the
    > callsign information, it is not pratical either "submitting" so many
    > times.

    That's not a problem either :). You can always upload the database information
    and have it handy on your web page. This involves long times for uploading
    it and quite a few MBs of RAM if your database is *big* [but again, but this
    can also be solved]. I do not think this would be the best solution, though,
    if the database is *big*. Other things to take into account is transactions.
    Will everybody be accessing the database from diferent points at the same
    time, and will they modify its data? We have a problem then, if everyone has
    its own copy of the database in its local computer...

    Well, only ideas... I do not know how contesting and casual QSOs actually
    work, and I don't get the whole picture of the problem. But it seems that
    those points that you made can be solved with the Web frontend.

    Regards, Alvaro



    This archive was generated by hypermail 2b29 : Tue May 16 2000 - 09:47:23 EEST