Christopher Hicks wrote:
On Fri, 15 Aug 2003, Wolfgang Pichler wrote:
found a visualized RD-scheme at http://irref.mine.nu/user/dchud/koha-scheme/ as a starter, but it seems somehow useless without a list of values used for indicator/status-fields or a list of constraints checked obviously programmatically in various places, or more bad, never checked and evocating hard-to-find delayed bugs due to perl's smatrness of operating everything somehow.
Can somebody put that URL somewhere that it's actually accessible?
sorry, but i had luck accessing it, seems to be some dyndns or mostly offline site, maybe. seems to be some old scheme compared with 2.0.0pre2 *.sql, but is a starter ...
And I seriously doubt that a quest to have Koha work with full referential integrity checked by the databse wouldn't be a worthwhile endeavor unless
[snip advocacy /wo prior offence] did you hear me voting for ref.integrity ? nope. so where is your problem ? i have teh problem if i want to do something with koha and lacking docs. IF migrating to koha, which seems to be supported, i hope, I HAVE to populate the db CORRECTLY. IF you can explain me how to do this without actually being able to understand koha most completely, because i have to jump deeply into the code, PLEASE do so. IF i have a chance to achieve a consistent data content in koha without keying in every biblio, item, borrower, category, etc.etc. in front of the gui from scratch, PLEASE explain. (nota bene: NOT just breeding infos imported from marc-records)
If you'd like to write that sort of documentation I'm sure someone will provide some web space for it. Honestly, "design after" isn't a bad thing for people that have some clue about implementing practical databses. And since you can obviously browse cvs and read perl you can find all of those code-quality misassumptions and submit patches. Right?
as stated before. please cite any words from me, which are speking of "code-quality misassumptions".. the only thing i stated, is that perl can be very funny with it's wonderful default behaviour. btw. personally i rely on such behaviour, and be honest, who ever has not printed undef's, intentionally or not ? i assume the web-space could already be populated to some degree by the people who know what they are doing. i think you also do NOT feel good to read megs of code for weeks until you get some idea, what is going on behind the scenes ...
so i do not expect some kind of petri-net, but if koha is a multi-developer-effort, at least some negotiated interfaces could be documented in some descriptive emails ...
Given how few people are actually coding and they seem to be making real progress, how much negotiation do you expect is still required?
do not expect ousiders to know project internals about number of devels, etc. obviously fewer people are involved, than i thought, as you tell me indirectly.
SO WHERE IS AT LEAST THE LATEST CVS ? sf ? looked at dates : seems, everyone keeps it's own copy and check-ins are rather rare.
That's a pretty normal developer pattern. Push things along in personal cvs until it's worth worrying about merging. It is generally better to put things out as often as possible and people may be pushing cvs commits after every day they've worked - we just don't know.
i agree heavily, slower moving targets are probably better. i appreciate your advocacy, but you are constructing offence, where none is. every developer including me dislikes documentation, but this gun shoots backwards. using koha means understanding koha for people who must operate it beyond the gui. this is a hard fact, like it or not. cu wolfgang