ADV: High-level cgi environment for filepro (was RE: fpCGI failure, part 2)

[Bruce Easton]

Fairlight wrote Wednesday, March 19, 2008 7:02 PM:
[..]
>
> That would be the nature of the CGI "environment"...the nature of the
> beast, so to speak.  Short of something higher-level like CodeCharge being
> built that will support fP, OG is about as good as it's going to get at
> the low level.  That's really the difference--high versus low level.
> And I actually have had a suggestion to write something like CodeCharge
> Studio (www.codecharge.com) specifically for fP, laying it on top of OG.
> It'll likely never happen from my company.
>
> Now STN...they're working on something that actually is a bit more like
> CodeCharge, letting you design/configure (Bruce, help!) easily at the
> higher level, and lays on top of OG.  And what I've seen of it is really
> cool!
>
[..]
Not my place to make any official announcement or promises, but yes,
we have been working on something specifically for OG, cgi and filepro
for quite some time - since late fifties I think it was...
Some keywords from above that go to the core of the project are
'high-level' and 'environment'.  High-level, as in keeping the
developer (or not-so-technical end-user) away as much as possible
from coding - and part of that is a set of high-level (browser-based
and parallel character-based) tools that allow the developer to
easily configure a JS+CSS-rich app. in a consistent, well-defined
manner.

One of the real strengths of filepro, IMO, is the relative
ease with which one can get started working and relating data.
Translating, as much as possible, that ability to quickly
build interfaces into browser tools for filepro has been
a key goal of the project.

Environment is the other key concern.  It is what ties the
tools togther and make them work together.  The tools are
easier to use when they are in the context of an environment
than just floating out there separately.  More functionality
exists between them because of the overall environment.
And the environment is what allows the tools to be flexible,
easy to configure and migrate to the developer's clients.
So there is a development environment and a runtime
environment for this monster, just as in filepro.
The development environment is meant to be really easy
out of the box for really basic development. But
flexibility in allowing developers to be able to reuse
bits of existing code easily and consistently in a
well-defined manner for transactional (and something similar
to auto and browse) processing is there as well.  So I guess
the question I'm constantly asking myself as I incorporate
more functionality or objects along the way is  - 'how do I
make this easy as pie to apply and then how do I easily
allow the developer to override this in a well-defined
manner?'

The runtime environment is what it is.  The basic needs and
desired features have produced the runtime env. (even though
I usually work on the runtime first - I tend to want to address
each need/feature with 'can it be done efficiently in the
runtime?' first, then code that, and then tackle the
development inerface usage of such feature afterwards).
The runtime env., though had to be efficient, as portable
as possible, and behave in a way that accurately reflects
what was advertised in the feature set.

Wish I could say more or speak more to time-frame at this
point, but not only do I not know, it's not for me to
initiate.  At least I can give an idea of how I think
about such a thing and some of my own requirements for
such a thing.  I'm hoping soon to have some online live demos.

Bruce

Bruce Easton
STN, Inc.