At the application level Inq has a type system, where things
such as persistence bindings, labels, preferred rendering widths
and formats are defined. These additional attributes are
captured within the application type and available for
clients and Inq's reporting engine to use.

At the language level Inq is typeless. Everything is represented
as a node of type any, which may contain other nodes.
Because of this distinction between the application and language
levels, Inq is able to offer high levels of functionality already
built in. Examples are aggregate operations (for example weighted
average) and sort.

Inq is parsed once then executed. Applications can be modified
while they are executing with no requirement for a restart.

Inq is is written in Java (requires Java 1.6) and is therefore fully
cross-platform. It treads very lightly on the various Java APIs it
uses (for example its transaction mechanism is its own; JMS
integration adheres strictly to the specification) so combining
Inq with vendor implementations of (say) JDBC and JMS holds no
surprises.

What About Clients?

The Desktop Client

At present Inq includes a desktop client that works closely with the
server. This client uses the server to maintain its state; events are
pushed both ways. This client also employs the Inq language and
presents the Swing components.

The client has access to all the application type meta data which
it uses to label and provide default dimensions for components.
Together with its layout models and syntax, these aspects make
GUI construction and maintenance easy.

As well as the standard Swing component set, Inq
includes Docking Frames and
a calendar component. Try out the examples from the
distribution, in ./examples/gui.

With its typeless node structure and events pushed from the
server, Inq automatically implements MVC between the node
space and the GUI components. This is another example of Inq's
built-in high level functionality that the users do not
have to write themselves.

Web Clients

This is work-in-progress. Inq already has a stream type that
produces JSON and we are in the process of integrating this
with the qooxdoo
JavaScript framework. The same server-side application types
and code can be used with both desktop and web clients.

As before, the application type meta data is included in the
JSON structure. The user-written JavaScript can be confined
to data presentation and input.

A servlet runs in the same VM as the Inq environment. Requests
from the browser are executed as Inq service calls and the
node structure produced is returned as JSON. By extending the
qooxdoo components to reference appropriate subnodes and meta data,
rich internet applications can be rapidly developed.
Application types and code can be reparsed in the server at
any time.

What Else Does Inq Do?

Desktop Components

Because the Inq language is typeless yet an application type's meta
data is available, many complex functions can be supported
completely independently of specific applications. For example,
the Item
Chooser
is a desktop client dialog that accepts some function arguments (Inq's
closure concept) and cooperates with the server to query and select
amongst a number of items. We expect this type of component to
translate to the web client environment as that is developed
further.

External Interfacing

There is a plugin architecture that allows existing Java code to
access the transaction environment. Such code can create application
type instances, mutate or destroy them within the Inq server's
transaction model.

Inq can call Java code via its callmethod function.

Report Writing

It is very quick and straightforward to write reports in Inq.
Once more, the meta data kept in the application types is
made available to templates when a node structure is transformed
into XML. Such an XML document can be transformed using external
tools, for example Apache FOP.

Examples can be found in the reports
produced in the Inq version of
petstore.

Get Involved

If you like the look of Inq and think it is missing something, or
if you would like to help with the web client integration then
we'd love to hear from you.

Get in touch at inq@inqwell.com

Inq in a Bottle

Whether writing and running client or server code, much of what the
programmer wants to happen is handled automatically by the Inq runtime.
Inq has been written to allow the developers of complex applications to
concentrate entirely on exactly that - only the application. Inq removes
two major facets of application development that are often traumatic:

The engraining of the chosen view of the "real world" in the code.
Inq is not an OO language. It has user-defined types but its simple
procedural approach and typeless language means that application
areas are not tightly coupled to each other. Maintenance for anything
unanticipated is unlikely to cause major rework or result in
duplicated or spaghetti code.

There are no multiple layers of software to integrate and write against
the APIs of. So no JDBC, no endless classes implementing this or that
interface, no transaction calls to make. No table models to continually
implement and to adapters to write. Inq is RAD in the extreme.

Inq Protects Your Investment in Legacy Systems

A "big bang" approach to upgrading your systems to the latest technologies
is rarely an option. Because Inq cleanly separates database schemas from
the application code, clients are able to migrate their existing systems
in discrete sections of whatever size they choose.

Inq will tolerate database schema changes much more readily than code
whose dependency on the SQL is engrained. As larger sections are migrated,
so the schema can be updated as required and the legacy code retired. The
pace and size of the migration is entirely at the discretion of the user.

The preferred method of implementing server-side application logic is
by expressing it as Inq code. However, legacy processing held as database
stored-procedures can be maintained as long as required. Inq can be
notified that a class or defined set of objects have been modified
externally, upon which it will resynchronise with the external data source,
raising events about what has happened as required.

Inq Instantly Distributes Your Application

Inq is a scripted language - it needs no compilation. The source files
are maintained centrally and downloaded to connected clients by the
Inq server.

Inq clients are indistinguishable from their traditionally coded Java
counterparts. Once parsed, the source is not needed again. With the
runtime available locally, Inq combines the instant distribution of
browser-based solutions with the rich functionality of desktop
applications.

Inq Efficiently Distributes Your Data

Inq propagates events between server and client according to whether
the client is observing the data raising the event. By only
notifying clients of the data they are interested in, Inq makes efficient
use of network bandwidth.

When retrieving large datasets, Inq can use compression to reduce its
network usage by up to seven times. Inq solutions solve the problems of
centrally managed applications often suffering from network bottlenecks.

The Inq server caches objects it has read from a database. Together with
the efficiency of its own client-server protocol, Inq operates effectively
when client, server and database are coupled over a wide-area
network.

Inq Brings Users and Developers Together

The speed and simplicity of Inq development means that users and
developers can work much more closely together. Developers can rapidly
produce and refine prototypes that users can see and try for themselves.

This highly iterative process becomes the de facto methodology of
development. The users and developers have confidence in each other,
leading to much better project management and a more assured delivery
schedule.

Inq Roadmap

Download Inq and try out the examples.
Read about Inq's implementation
of petstore for
a good appreciation of what Inq is. Then learn
more about how Inq works and the issues it addresses.