Path: utzoo!attcan!uunet!munnari.oz.au!metro!bunyip!brolga!ggm From: ggm@brolga.cc.uq.oz (George Michaelson) Newsgroups: comp.protocols.iso.dev-environ Subject: Re: How Serious are we about running quipu? Message-ID: <.640006777@brolga> Date: 13 Apr 90 11:39:37 GMT References: <1990Apr11.025837.6749@metro.ucc.su.OZ.AU> Sender: news@bunyip.cc.uq.oz.au Lines: 126 gopher@extro.ucc.su.oz.au (John McQueen) writes: >I guess these questions are directed to all those DSA managers out there. >How serious are you about running quipu? Very. Having shifted from a department-pays-for-use system of networked and central computing resource usage to centrally funded "the network is infrastructure" models we badly need to get on top of a general information management problem. QUIPU fits the midterm bill well as an (albiet researchy but...) sufficiently robust version of something that we can point to and say to the infidels of management "look what we got to try and fix our problems" and other good noises. We'll stick with it until something better comes along, and I dont see anything looming on the horizon yet! >I know George Michaelson at the University of Queensland (Australia) >seems to have the entire payroll of the university loaded up. This is a bootstrapping exercise. getting enough data online quickly to justify further funding is a pain! Adding nicer info into this framework is taking time, primarily phonelists and /etc/passwd type info. I hoped to get some campus-context specific oid stuff together but I am very nervous of departing from globally meaningfull information models, and would LOVE to see what other people consider "useful" information types. One that springs to mind for us is: mapReference :gridlocation a la A-Z guide or numbered building map Since we want to see this used for more general "whois and how do I find her" searches eg from S.U. refectory & library installed terminals. >Here at Sydney University we are a bit unsure as to how far to go with >it. Whether to suggest to the admin people they use it for maintaining >their phone book, or just let things go along and let our data go slowly >out of date. I am VERY nervous of taking so long that the data becomes stale. I'd figure anything that lags more than 3 months on the real world is getting dangerously old especially with the new PABX coming in (lotsa phone number changes) It is VERY tempting to "sell" QUIPU to mgt as the answer to their prayers, but when facing somebody(somecommittee?) that just spent $x000 on ORACLE or some other DB for MIS applications It can get a bit embarrassing. I personally DO want to try and get QUIPU wedded into the general staff appointements process (so that you are online from day #1 of your working (students comes later I suspect) life at UQ, if you use email or not) but I think I'm going to be moving a bit slowly towards this. I'd like to demonstrate an ability to handle plausibly complex information before I commit and I mean "manage" at the human level, I don't doubt QUIPU is up to it. Security of personal data looms large as a user-specified worry. Its one thing to choose to have your mugshot stored online, but getting it done by default scares the hell out of me. Ditto home address/phone info (yes its in the phonebook but you can't do fast context-sensitive searches through there unless VERY committed to chasing my (paranoid) tail) >My personal thoughts are that if we are going to do this then me may >as well do it properly, and each organization make some sort of >commitment in money/manpower to maintaining an uptodate complete >directory. Definitely. The exact level of funding is hard to pin down though... initial h/w costs locally we fudged by getting a good "porting" discount (thanks guys) but labour will FAR outweigh this if you add up: 1+ Database Manager 1 data entry team secretarial staff committee to manage above and integrate into general admin re-print stationary as longterm costs. You have to sell an increase in functionality rather than definite savings I think... well you can suggest email based comms is cheaper than paper, but the directory is only 1 facet of that argument. Its trying to sell MHS/networks WITHOUT a directory that doesnt make sense the all look to the net as a phone-like system and expect a directory to co-exist with the comms packages from day 1 (and I dont blame them! we must be crazy to accept a global net with no directory!) ...Not to mention help/docco/porting and fending off people who want you to run product instead... (sigh) I did a report for the Qld state government computer centre on directory and naming issues in their network. I did a pretty cack-handed job of it, but one solid thing came out of it for me: You are walking on a LOT of sensitive feet when you try and structure a namespace and manage it longterm. Selling a specific package or system is not nearly as important as selling the IDEA of a managed namespace for ALL communications (you can interpret managed in any way you see fit including deliberate anarchy) and you are looking at a small to medium sized department which has to exist longterm for any body of more than trivial size. I personally favour taking QUIPU as a starting point and generating a good enough demonstrator to hand it over to somebody else for integration into the local system. I suspect I wind up selling my own org within the university as the body to manage it since nobody else is likely to take it seriously. The phone-net and even campus video people are already being softened for takeover by the campus computing body so this probably makes sense longterm. If we wind up using some mix of Kerberos-like and QUIPU for Information access and access control I'll be pretty happy. If we wind up with one single mechanism for both I'll be deliriously happy. Wanted: Cheap/free PC/MAC --->integrated<--- X.400 and X.500 tool. We already have back-ends for these. we need the user interface. Should preferably mask underlying server architecture (unix vs VMS) -George G.Michaelson Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079 Postal: George Michaelson, Prentice Computer Centre The University of Queensland, St Lucia, QLD Australia 4067.