On 11/14/06, Xavier Hanin <[EMAIL PROTECTED]> wrote:
On 11/14/06, easyproglife <[EMAIL PROTECTED]> wrote: > The next step is to create a simple, thin, flexible and scalable > architecture. I'm obviously biased, but I'm not sure we should create a brand new architecture for Ivy 2.0. It took a lot of time to create Ivy 1.x, restarting from scratch with a brand new architecture seems very ambitious (and dangerous) to me, at least at the time being. Moreover, what does it mean to migrate Ivy to apache if it's only to create a brand new and redesigned version. Why not create a completely different project? I would be more for refactorings, with discussions about the target design, but with some respect to existing and working code - not because I'm sentimentally attached to this code, but simply because I think it's the better way to get a 2.0 version a reality, and not only a dream :-)
Sure! I agree. Ivy architecture is great! What I meant is to refactor where needed and to invest some more work towards a stable API. (One simple example: latest strategy API (on 1.3.1) gives you a list of revisions and a date. I expected to get also the requested status - e.g. " latest.integration" along as a parameter. This is a little refactor, not a full redesign. ) What I mean flexible and scalable is for example evaluating how complicated it is to write a DB based repository. It could be direct SQL driven or wrapped by an HTTP server with dynamic content, in contrast to raw HTTP URLs as today. Thinking about such possible enhancements can lead to better design and architecture. That's what I meant and that's where I want to go by collaborating ideas using the Wiki. easyproglife
