Re: [Firefly-dev] About the xml way

[firefly-dev]

The main thing with them having to know alittle about what really goes
on is that if something breaks or if something needs to be added than
they have to know something about how it works. In my library we use a
very cryptic scripting language. It is very hard to add features and if
you really need something you have to pay thousands of dollars for a
company to make it for you. I would like some aspect of the app so that
they have options to change things.
John Hornbeck

On Wed, 2003-04-02 at 11:01, address@hidden wrote:
> On Wed, 2003-04-02 at 15:30, address@hidden wrote:
> 
> > Hello, In CVS I am not sure how much room we have. I know we should have
> > alot though so feel free to add the directory structure to the test
> > folder. I know some of what I am about to say has been covered but I
> > need to let everyone else hear what has been communicated to Gimpy.
> > This project comes from a frustration of working with bad library
> > software everyday. I get tired of writing cryptic MARC files.(MARC is
> > what most libraries use). I want a DB that is independent of its
> > platform, I also want software that a moron can work. I know that not
> > every library has a Sysadmin but most have a librarian who tried to
> > figure it out. I would rather come up with something that has a small
> > learning curve as apposed to making someone learn any of the sql's.
> > There is already a free library system that runs off sql, Koha. I do not
> > like the way Koha works and I would like to avoid being stuck in one
> > possition for the rest of this things life. If we figure out our own DB
> > plan and how to store our own files in a format that is easy to read and
> > write to than this will be easily adapted by libraries. Librarians most
> > the time don't have alot of time to sit and learn a bunch of new stuff
> > just so they can get their new system working, if they have something
> > with a small learning curve that they can install on just about any
> > platform be it, Sparc to ppc to x386. I want to see this be the best
> > thing out there for libraries. If giving up alittle speed for alittle
> > easier learning curve it is worth it.
> > John Hornbeck 
> 
> John I didn't know these were the motivations for the project, I thought
> you just wanted a free library system, also I have never heard nothing
> about Koha so I didn't know that there was already something similar.
> (i give it a very brief look but is it all web based ?)
> 
> I understand your frustation in using bad software, however I have never
> used MARC so I don't know how it works.
> 
> In the library where I worked the program used had a lot of functions
> but for the most common operations it was quite easy to use.
> To loan a book, for example, you needed to go in the loaning menu (press
> 3 than 1), scan with a bar reader the card of the user, press enter,
> scan with bar_reader a label with a barcode on the book and press 3
> times enter to confirm dates. This took 10 seconds for the slow
> librarians and 5 for the fast ones.
> This was the procedure in all the libraries except one, in the main
> library it was even easier for librarians to loan books, they simply
> needed to pass the book and the patron's card on a reader like those
> used in a supermarket. I don't know the english name sorry :(
> 
> I explained this to say that is not the language you use that make the
> software easy to use. 
> I absolutely don't have intention to make the librarians use sql or even
> xml. In my idea librarians just have to push bottons :)
> Libraries just need to use the ui (graphical or not), they don't need to
> know how the app works or where and how are stored files.
> Once I asked to a my co-worker if she knew how was organized the db and
> how the db were updated between libraries(actually this happens using
> crontabs during night cause every library has its own db), she answer me
> something like this: "db ? what's a db ?" :)
> 
> The user interface should be built on top of the app, we must separate
> the levels of the application, this is why I mentioned OOP in one of my
> previous messages, because we need some levels of abstractions and
> because the app should be modular(and here python rules ;))
> 
> Marco
> 
> 
> 
> 
> _______________________________________________
> Firefly-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/firefly-dev
-- 
John Hornbeck <address@hidden>