Re: UP -- patent restricted?

On 2006-07-12, Luke Webber <luke@xxxxxxxxxxxxx> wrote:

It appeared to me that Michael wants UP as a 4GL, not as an editor. A
tool for building applications, which will in turn be used by some poor
unsuspecting schmuck.

The schmuck won't be unsuspecting, and 4GL sounds a bit grandiloquent,
but perhaps I'm out of touch. Yes, it's an automatically generated
data entry screen. That's what I want.

I want something to meet a need that I feel. Maybe no-one else feels
it. So maybe it will be used by no-one else. The objective is not to
develop something for someone else, unsuspecting or not.

Maybe there is a better way that I am ignorant of. Maybe (very
probably) there are capabilities in SQL (as it has so far been
implemented in PostgeSQL) that I'm totally ignorant of. It has just
occurred to me that doing these things was absolutely simple and
convenient with UP.

I'm just looking for a simple way of doing data input and update. In
particular, updating a text entry of about 10 lines (maybe an invoice
narration) to correct a spelling error, doing it with SQL, at least at
my level, means typing out the entire text again, and hopefully
getting it right this time, as part of an SQL update command. I want
to simply edit the existing text.

To confess, I'm a forensic document examiner. I charge by time. I
capture time and at the same time I type two kinds of text entries,
one a narration that will appear in the invoice and be perhaps two or
three lines long, just saying what I'm doing just now, and the other,
examination notes, what I'm seeing just now, and in a lot more detail
what I'm doing just now: some of which will eventually find its way
into the report. So between time A and time B for this client, this
rate, this charging system and so forth, I have in addition two text
fields.

After doing that I'd like to "ride the B-tree index" to visit and
check all the entries for this client. It is very easy to overcharge
if you had the timer on and the phone rang. I may need to enter time
in the "deduct" attribute for some of these entries. I want to be
able to visit them all in some order, check them, and perhaps, while
I'm doing that, update them in these several ways.

Doing a SELECT (an SQL one), printing all these items out, in the
first place makes a confusing mess with multiline entries, and then,
as a further process, you have to make the corrections with a series
of SQL statements.

Although PostgreSQL has indexes and indexing methods at least
equivalent to the B-trees of AP, in this different world things will
have to be done differently. Data independence, the desirability of
an update method that will work with views, the advisability of doing
everything via SQL and the virtual infeasibility of by-passing it if
you don't have a spare 50 years to study the code, these factors must
lead to an approach very different from that of AP and D3.

It will probably be a select list approach. You would select only the
indexed attribute, order by that attribute, store the list somewhere,
and then step through it, rather than stepping along the index.

On the subject of key mappings I do remember railing against the
absurdity of the UP choices when I first encountered UP. And I
remember thinking, why in the heck didn't they just... and then
realizing that virtually every key on the keyboard had been mapped.
When you need so many keys, i.e. you have so many functions, so much
functionality, you don't have a lot of freedom to conform with what
others have done. Emacs maps most keys, but most of what UP does you
can't do in Emacs. You need as many keys again.

In such a situation it is reasonable to start afresh, to independently
define a set of mappings. It seems to me that that is all that ***
(if it was ***) did. In the circumstances it seems silly to
criticise those choices on the grounds that other applications do
other things. It is a totally invalid criticism.
.