Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 8675 invoked from network); 13 Jun 2002 11:20:42 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Jun 2002 11:20:42 -0000 Received: (qmail 13608 invoked by uid 97); 13 Jun 2002 11:20:43 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 13592 invoked by uid 97); 13 Jun 2002 11:20:42 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 13580 invoked by uid 98); 13 Jun 2002 11:20:42 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Sender: ulim@denic.de Message-ID: <3D087F4B.C82F329F@denic.de> Date: Thu, 13 Jun 2002 13:17:31 +0200 From: Ulrich Mayring X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Avalon-Phoenix Developers List Subject: Re: management GUI References: <8097298F8B57D5119F87000102C3D61106513D@mail.infogation.com> <1023919498.1820.523.camel@lsd.bdv51> <3D07C5C3.7060904@apache.org> <3D084C04.55B316F5@denic.de> <1023986789.1417.6.camel@lsd.bdv51> X-MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.8 |June 18, 2001) at 13.06.2002 13:20:05, Serialize by Router on notes/Denic(Release 5.0.8 |June 18, 2001) at 13.06.2002 13:20:06, Serialize complete at 13.06.2002 13:20:06 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Leo Simons wrote: > > If I can deploy a client/server setup where I provide a client with two > files (server.exe and client.exe) he'll be impressed. Nevermind that > there's no advantage over a swing client over a web client for > management of avalon itself -- there's an advantage when you can > customize the client to also manage your blocks...some people might be > using the client all day long. The JMX-based web interface (we're using it with MX4J) is absolutely sufficient for management tasks. I think it's overkill to provide more than that for the simple task of managing and configuring Avalon / Phoenix itself and my own SAR applications and blocks. However, it is not sufficient for real web applications. It is not customizable enough for that - maintenance becomes hell, if you leave the generic path. So, if the general plan is to build the client-side to a web application, whose server-side is a Phoenix app, then I'm all for it. However, this will probably duplicate efforts with the Cocoon project. Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung -- To unsubscribe, e-mail: For additional commands, e-mail: