Robin Berjon wrote: > On Thursday 25 October 2001 12:26, Matt Sergeant wrote: > > On Wed, 24 Oct 2001, Paul Kulchenko wrote: > > > Messaging > > > Authentication/Identification > > > Sessions > > > Webservices > > > Security > > > Database Access > > > Auditing/Logging > > > Exception and Error tracking > > > Workflow Management > > > Configuration > > > Internationalization > > > Transactions > > > Directory > > > Testing > > > Deployment > > > Documentation > > > > You forgot: XML. Yes, it fits into lots of the above, but I think it also > > requires its own set of APIs (like JAXP). > > Definitely. In fact, I think that some frameworks will be more foundation > packages, on top of which others will build. Those probably need to happen > first. > > On the foundation side, I'd list: > > XML (mostly JAXP/PAXP and probably a few helpers) > Configuration > Logging > Exception/Error > I18N > Testing > Documenation > > Of course, this doesn't mean that we'll have to have all of these complete > before the rest can be worked on, but simply that the rest will likely have > to a certain extent to be retrofitted to work with these. >
Hi, I'm new to this list, so sorry if I'm going over already existing material. Whilst I agree that a foundation is necessary, I think it might be prudent to seperate the functional components ( XML e.t.c ) from components that provide the backbone for the application server it's self ( Exceptions/ Error handling ). A lesson could be learnt from perl - formats and such are being taken out of the core and moved into a module. Perhaps defining the functional layers required would be a nice start. So that at the base you could have a foundation layer, which would define how the components communicate, and the order in which they are called, also facilitating asynchronous and synchronous activity. On top of this, An application layer, which ( if the project were based on mod_perl ), would handle some decryption of data, session management, and turn real world post/ requests into a model more suited to development, such as a validate - process - return model. On top of this would be the application - which could use XML, just as it could use an RDMS, flatfile e.t.c. Comments / flames welcome, but please be constructive Cheers, Steve. -- The opinions and content of this message are personal and not those of my client. I'll change to using a personal email account later.
