Has anyone considered chromatic's Jellybean as a place to start the discussion on objects?
>From http://wgz.org/chromatic/jellybean.html#features "Version 0.13 (26 June 2001) is an important milestone. The infrastructure is in place to do very cool things in the future. Soon, you'll be able to access Containers and Objects via XML-RPC. If you code them right, you won't even have to edit them when we add support for other access methods. Amazing! This also means that you can listen on multiple ports. " Jeff Bulley [EMAIL PROTECTED] 02/05/2002 12:50 PM To: Stephen Adkins <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: Re: P5EE concerns raised on Perl Monks On Tue, Feb 05, 2002 at 12:11:14PM -0500, Stephen Adkins wrote: > We define "Enterprise" and even "Software Architecture". > > http://www.officevision.com/pub/p5ee/definitions.html > You define the environment for the problems for which one wants a solution. But you do not describe the problems you want to solve. That is a big difference. the platforms page gives some hints (distributed code or not etc.) but that is not enough. > The Physical and Deployment Views of architecture are also lacking, > but a description of the Platforms to be supported is included > (which is related). > > http://www.officevision.com/pub/p5ee/platform.html There needs to be more detail there. Multi-Site Cluster describes the setup of machines somehow. But you need to know a lot more things, like the failure classes that should be handled (for example site and/or communication failures). > We are kind of at the awkward stage where we all think that a P5EE would > be great, but there is not even the kernel of a codebase to rally our > discussion around. > > So all on the list were invited to create prototype code that could be > critiqued and debated and form the beginnings of a code base. > (Code speaks louder than words.) It seems that my evolving code > base is the only prototype anyone has chosen to make known > publicly. So until I get to a point where it does something worthwhile, > we're all kind of waiting. Then hopefully, there will be enough > infrastructure that we can start critiquing, agreeing, and handing > out tasks. In the mean time, the list remains a useful place for > people to exchange knowledge relevant to the effort. That is the wrong way around. At least if you want to avoid starting from scratch. Distributed applications are totally different to distributed ones. If you cannot make the parts work on different data sets a LOT of problems will arise. Analysis isnt done yet (see above), design even less, what should we do with code ??? How should anyone start developing something, if there is no agreement on the basic facts ? How to handle shared data in a distributed setup? How to address objects? The list goes on and on ... There weren't any replies when I wanted to start a discussion about that. If all of you think that this not that hard and will resolve easily in the end, plese tell me that. To me it seems like you will either come up with a nice single process model framework or will end in chaos. Torvald
