On 11/15/06, easyproglife <[EMAIL PROTECTED]> wrote:
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.
Ok, so we are in sync with how I see the future of Ivy on apache. Let's continue contributing and organizing ideas on the wiki, and see how we can address them. About the API I strongly agree too, there is work to do in this area to stabilize them, so that Ivy can better be used from other tools, and more easily be extended. Xavier easyproglife
