[pyswarm-devs] Basic GUI set-ups

[Anastasios H. <ah...@ha...>]

=46ollowing, two set-ups for graphical user-interfaces (GUIs) of pyswarm-ba=
sed=20
applications:


Stand-alone, all-together installation:

All components will be installed on a single host, likely a PC. This would=
=20
include databases, business components, and GUI. The end-user might have=20
administrative privileges, for example, to install or remove software.

This use-case is special since it would allow us to avoid many=20
(time-consuming) network features between the components of the installed=20
pyswarm application. So all client libraries should support direct access t=
o=20
another component (e.g. "import componentFoo") instead of starting to handl=
e=20
plenty of wrappers designed for networking.

Beside that, principally I don't see any performance or hardware resource=20
problem for today's average home PCs or business PCs. Recent PostgreSQL=20
versions perform pretty well, CPU and RAM consumption is low and goes down =
if=20
the database is just idle. Assuming such application would not incorporate=
=20
overchallenging computation in the business logic layer, the biggest part o=
f=20
system load would be caused by the GUI.

This set-up could be the favorite local testing environment for pyswarm=20
application developers. They can easily run iterative tests on their local=
=20
host to see results of changes in the GUI or business logic. This may happe=
n=20
multiple times per hour. Of course these tests won't redundantize final rea=
l=20
tests with full network operations. But just imagine how nice it would be i=
f=20
you could quickly check features or behavior of particular components while=
=20
designing or coding - and not thinking of network issues or even side-effec=
ts=20
to stable components that already run in production system.


Desktop server:

Many users share the same desktop server over the network. The server hosts=
=20
the GUI of the pyswarm application, but installation *may* also include=20
backend-components or access them over network. Installation and removal of=
=20
software on such hosts usually are done by system administrators, not by th=
e=20
end-users.

AFAIU, virtual machines or physically distributed clients actually are noth=
ing=20
else as the desktop server set-up.

In order to reduce administration efforts and ease an automatic upgrade=20
process a pyswarm application I consider to separate the GUI into mainly tw=
o=20
parts: the part that is installed locally should have the client lib, widge=
ts=20
and other code that will need only update if the developers decide to upgra=
de=20
their pyswarm application to run on a newer pyswarm runtime environment.=20
Application-specific changes (workflows, dialogs and so on) will not requir=
e=20
any update of the GUI itself. Maybe it is possible to use wxPython's suppor=
t=20
of XRC for this. An XRC-file contains an XML-formatted specification of=20
widgets (e.g. layout, buttons, labels, ...) and the GUI app would parse tha=
t=20
XRC files and render the dialog with its content.

So deployment of GUIs would actually be a kind of frame on the client side=
=20
with a library of all widgets supported in a pyswarm application's GUI, let=
's=20
call it a "dialog controller". This dialog controller would interact with t=
he=20
back-end on a server, say a "dialog agent" which accesses the business=20
components and workflow controllers

The pyswarm SDK would at design-time create all XRC files, that are deploye=
d=20
to the server only. At run-time the dialog controller of the client would=20
send a (user) request to the dialog agent. The dialog agent asks use-case=20
controllers in the business components or workflow controllers for the=20
appropriate actions to take and will send back an XRC file to the dialog=20
agent. The dialog agent then renders the dialog and presents that to the=20
user.

Whenever a developer changes a pyswarm application it would be sufficient t=
o=20
generate the server-side controllers and XRC files, and then deploy them on=
=20
the server. After a server-update all clients would just get served the new=
=20
XRC files.

Conclusion:
So, there are no updates on dozens or hundreds of clients. No end-user with=
=20
administration privileges required. No out-dated client versions. No broken=
=20
business logic.

Did I forget something? What do you think?

Anastasios