[Glass] General questions about how to develop ...

[Otto Behrens]

> -> When starting, the development is done with Jade and the user
> DataCurator.

Consider developing in Pharo and deploying in GS. If you want to use
refactoring tools and get speed.

There are some discussions in this mailing list on the topic. And
there are some compatibility packages that make it easier.

> -> Now I would like to run the end-user application. Should one create
> another db user to run the end user application ?

Most definitely. You should have a separate VM with its own setup and
upgrade that once your developed software is well tested.

> -> this end-user application is running in its own gem, right ? Must I
> use Topaz and several filein (in a batch) to import the sources and then
> start the application from within Topaz ?

In principle, yes. The end user application runs its own stone and
possibly load balanced gems. These gems are topaz sessions started up
by scripts in <your GS installation>/seaside/bin.

You can use Metacello / Monticello to load the source. So you save it
from your development environment in a Monticello repository and then
get it across to your end user application. On that system you use
Metacello to load it in again.

> -> Can I develop further on (in parallel) with Jade and DataCurator ?

You can do that. But surely you may break the application while you
are working if your end user is on it at the same time?

> -> can I update the running end-user-application while it is running to
> get new method versions - or do I have to stop that gem and restart it
> again  ?

It is possible to update while it is running. But it could have
adverse effects if the timing is off (i.e. if you updated 1/2 of your
methods and commit, the other 1/2 of your methods may be required to
make the first ones loaded work). So, not recommended unless you know
exactly what you are updating (and it's a small update). Safest is to
stop the gem, update and start it again.

> When developing server applications - which I really would like to do,
> if I could at least file in all needed sources do I understand it correctly:
>
> - that within a gem only ONE request at a time can be handled (also due
> to global transaction management)

Yes, but if your requests are handled quickly, a queue of requests can
be serviced in a short time. You can also start up a few gems and
multiplex over them. (Discussions on mailing list re. daemontools,
FastCGI and reverse proxy.

>   - that means: wait for request, abort transaction, do request work,
> abort or commit changes, wait for request  etc ...

Yes, each request is a transaction on its own. In GS 3.1 you have
nested transactions with the ability to abort some changes. We
currently always commit (and validate before that).

HTH

I've just given broad explanations, please feel free to ask more questions.

Otto