Jean-Baptiste!
>I would be interested to know more about that "qooxdoo big project" I heard
>for a while now.
>Could you tell us more about the functional domain for example ?
In general terms it is a big application of administrative
character and it already exists as a java client server solution. The customer
wants it to be converted
and upgraded for a web browser based client environment. The user "load" of the
system varies between
3-4000 concurrent users.
>Is it dedicated for a company internal use or is it intended to be public ?
Most is internal and some parts for external use.
>Also, I would be interested in more general aspect than purely qooxdoo : the
>software architecture you had choosen.
>What is the backend ? What other framework are you using on the backend or
>elsewhere ?
>Are you using a relational database ? If yes, which one ?
Our server setup is based on Linux, Fedora Core.
Linux is configured for virtualization using Xen
Qooxdoo for client gui
Java-Rpc which we have changed to fit our needs to communicate with the
transaction servers. Now
a little more secure!?!?!?
We use Java for the backend server software.
We run Java in JBoss containers.
and JBoss runs "in" Terracotta for redundancy and distribution of cache.
We use a modulated JPersist as persistence API, http://www.jpersist.org/
We use database connection pooling compatible with JPersist.
We use Oracle and MySql as database servers.
>How are you dealing with "fat client" pattern induced by qooxdoo ?
>I think this is a very positive thing so the server can concentrate on server
>things.
We have actually so called workhorses, transaction servers, in between doing
all the business logic. Qooxdoo
is nothing else than javascript and security is limited. Things can be changed
and tested. By publishing, which
you do if you include business logic in the client code, you become more
vulnerable to attacks.
We have chosen to use qooxdoo only for the client web gui and only included
logics which is understandable and
not revealing the whole logic. Passed data to the servers are going through so
called workhorses for
validation and business logic.
Our advice, keep qooxdoo as a pure gui client with as little business logic, if
any, as possible.
>By the way, I find very useful to have the previous element of context in
>email reply.
>I'm not sure why all your emails had no previous context, so it is hard for me
>to follow the thread in a classical email client as I have.
Sorry about that.
Stefan
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
