Anyway, one thing I would have to say is that this type of thread is somewhat annoying.
It seems that everytime someone posts a list of subsystems to do, everyone with their favorite subsystem will start to talk about details of the subsystem and then the thread becomes convuluted with exception discussion and security discussion and ...etc... enough that it makes it quite hard to follow because the details tend to get discussed too early on. This is a major reason why I am only responding now. I am not sure how to stop it other than I would make the request that you guys please talk about the details of any one or related subsystems in separate posts rather than making them (the emails!) large and monolithic. :) You will likely get more response that way too because people who are interested in a particular subsystem will be able to discuss this at some point. For example, I am decidedly not interested in the details of exception handling and config docs. Those who are interested in coming up with the API and code for that which would be recommended for me to follow, feel free. However, I am interested in naming, security, and messaging interfaces (in that order). And moderately interested in other stuff like sessions. But if the posts here become monolithic discussions that is hard to wrap my tiny head around, then I will be less likely to contribute. Of course, I am not saying that this is a bad thing (my contributions might just add a lot of fluff at this stage which might not be a bad thing) :) but perhaps for others it is a bad thing that they may be less likely to contribute if the threads aren't controlled. Normally I wouldn't be such a Nazi on this list except that all P5EE topics are pretty much heavy intellectual exercises -- more so than many other mailing lists which are more concrete and centered around a set of code. Here we have a set of ideas that we are trying to make code, and so the conversations are many and the discussion about the way to do things has a high quantity. Every post on here seems quite good in terms of content, but at the same time, I find it hard to follow many times precisely because I feel like I have to read each post on this list very carefully to get the nuance of something someone is trying to say. So I guess what I want to start doing is relegating my post reading to just a few P5EE subtopics that I am interested in helping influence rather than such a large set. Anyway, I feel that your intention was just to discuss high level subsystems, but I saw a lot of off topic stuff being posted and it made it quite hard to digest until now.... so I would just ask that if subsystem organization is being discussed, then let's just discuss that and not details of the APIs until the subsystem itself has been decided upon. At 01:50 PM 11/22/2001, Stephen Adkins wrote: >Hi, > >I have done a lot of work over the last few days putting >together a major new architectural framework proposal. > >It is documented here: > >http://www.officevision.com/pub/p5ee/software/htdocs/P5EEx/Blue/ > >Basically, it lays out a component model for P5EE: > > Context > Config > Serializer > Service > Security > Templates > Messaging > Repository > Widget > Log > >Each one of the components essentially represents an interface >(or abstract class, or a base class with default functionality) >which can be implemented using any of a number of physical >implementation classes. > >For a quick overview of the whole scheme, go into each component's >page and go immediately down to the "Class Group: <Component>" >section. This will give you a good idea of what possible >implementations for each component that I have envisioned already. > >Of course I am interested in feedback. > >I am eager to move out of the "random posts to the list about >your favorite technology" phase to the "let's hammer out an API" >phase. But that can't happen until we reach some agreement >on how to organize that all technically. > >If some people think it's great but not most, I would welcome >you to join me in building up the P5EEx::Blue namespace. >That's what the experimental areas are for: proving ideas. > >Stephen > >P.S. All of the documentation was created in POD in order to > communicate in the same basic way that Javadoc does. > Meanwhile, the data is reasonably structured so that it > may be parsed out by some future tool. > >P.P.S. Happy Thanksgiving for all in the USA.
