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]

Reply via email to