A user view: What I want as a solution provider is a stable ( i.e. reliable, not frozen ) platform to deliver services. I want it to evolve as both hardware and software evolve.
I want it to be pure Java, but I don't particularly care how it is implemented - meaning within a container / framework technology or stand-alone - as long as the implementation does not in itself introduce a support burden to me. I don't want future versions to be continually backward-compatible in terms of environment - thus, for James in particular, I would like V3 to abandon J1.3 and adopt 1.4 as its minimum. Not because that especially matters to me as a provider, but in the expectation that moving forward would allow the developers to produce better internal code ( meaning more efficient, not better quality - no developer criticism intended ). However, I would be expecting 1.4 to be a better environment than 1.3. I am also a little nervous about James using Phoenix going forward, but only because Phoenix appears now to be frozen. However, given a finite amount of developer resource, I would prefer that resource to focus upon delivering new function to me as a service provider rather than toiling away under the covers to simply deliver the existing function within a new environment. Regards, Roy -----Original Message----- From: Paul Hammant [mailto:[EMAIL PROTECTED] To: James Developers List Subject: Avalon - moving away from ? Is there any interest (beyond me) for refactoring the James server implementation to allow non-Merlin/Avalon use ? Thoughts? - Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
