The repository server architecture and session
management system needs some work. As I mentioned to
Mike Olson:
> >From cleaning up server config so that it is easier
to use 4Suite to
> combine several apps on one port to completing it so
that you don't
> *have* to use the buyerbase-type magic to use
sessions in real life (I
> have some of this in place, but it need a bit of
rounding out, and
> probably a good deal of testing)
Mike responded:
"I already added one about getting much of the FtServer
config file stuff
out of that file and into the repo but we definitly
need a way to do the
port combining more easily. Should this be part of the
install app?
"I don't understand the buyerbase-magic that you talk
about with
sessions. Is it how you configure them in the
server.xml file?"
Currently sessions in Buyerbase occur through magic
entries in the config file, but there are problems,
including the fact that the session management in
virtual hosts clash (and that it's hard to even have
different session handling in separate sub-applications
within a single virtual host).
What we really need is to put long thought into the
host, server and session architecture, bearing Apache
in mind, but not aiming to do everything that Apache does.