> > 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.
that's okay. It all depends on how complex the blocks is whether you talk about a "simple task" or not, though. For example, I have an elaborate CMS with phoenix as the backbone. I'll be building a GUI for that; it'd be so easy for a user if the management of phoenix was just another button in that GUI. > 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. hmm. Phoenix already has pluggable management protocol (the only one atm is JMX though). I'm thinking either a client that talks to the MBeanServer in phoenix, or one that talks to a different kind of server (maybe SOAP or something BSH-like). cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
