Re: RE: vendors and usability

>Once you've got a fairly robust codebase, even if it's 20 years old,
>it's usually more feasible to keep going on with it.  After that long,
>you're bound to have gotten rid of a whole lotta bugs. Of course it's
>often very brittle -- you add shiny brand new feature X and it breaks
>breaks some piece of code that nobody's even looked at in 18 years. 
>Or it comes to the point where it's just impossible to develop it any
>further.  So yeah, does an ILS have to be 3 million lines of from
>scratch legacy code?  Heck no.  Are there any systems out there that
>were written after 1999 or so, designed bottom-up in an enterprise
>programming language like Java or C#, using standard RDBMS technology,
>supporting standards from the 60's (MARC) to today (SRW/U, VIEWS,
>etc.) and built around robust, widely used components?  I know of
>several in the pipeline, but none that you could go live with today

True, I guess the promise is that the development cycles may get smaller 
every time. The RDBMS solved some huge persistence and transaction issues 
when it became a standard part of the ILS, and if we reach a point where 
constructs like general ledgers can be acquired from mainstream sources, 
then the next generation of ILS applications will have a lot less lines of 
code and much more potential.

art
_______________________________________________
Web4lib mailing list
Web4lib@...
http://lists.webjunction.org/web4lib/