From perhans@indexdata.dk Thu Sep 21 11:14:39 2006 X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] ["5714" "Thursday" "21" "September" "2006" "11:50:11" "+0200" "Per M. Hansen" "perhans@indexdata.dk" "<45126053.701@indexdata.dk>" "149" "Re: Target classifications" "^From:" nil nil "9" nil nil nil nil nil nil nil nil nil] nil) Return-Path: X-Original-To: mike@localhost Delivered-To: mike@localhost Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D7051ABB25 for ; Thu, 21 Sep 2006 11:14:39 +0100 (BST) Envelope-to: mike@indexdata.com Delivery-date: Thu, 21 Sep 2006 11:50:47 +0200 Received: from localhost.localdomain [127.0.0.1] by localhost.localdomain with POP3 (fetchmail-6.3.2) for (single-drop); Thu, 21 Sep 2006 11:14:39 +0100 (BST) Received: from user.indexdata.dk ([213.150.43.10] helo=[10.0.1.61]) by bagel.indexdata.dk with esmtp (Exim 4.50) id 1GQLCh-0000nn-JE; Thu, 21 Sep 2006 11:50:47 +0200 Message-ID: <45126053.701@indexdata.dk> Organization: Index Data ApS User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 References: <450FBF59.8270.00DD.0@sedubois.k12.in.us> <451126FB.8030005@indexdata.dk> <45112774.7070705@indexdata.dk> <17681.12470.646110.396726@localhost.localdomain> <451131CE.3040203@indexdata.dk> <17681.17678.192303.760970@localhost.localdomain> In-Reply-To: <17681.17678.192303.760970@localhost.localdomain> X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 213.150.43.10 X-SA-Exim-Rcpt-To: mike@indexdata.com, quinn@indexdata.dk X-SA-Exim-Mail-From: perhans@indexdata.dk X-SA-Exim-Scanned: No (on bagel.indexdata.dk); SAEximRunCond expanded to false X-UIDL: %l>"!C@~"!b0,#!o@V"! From: "Per M. Hansen" To: Mike Taylor CC: Sebastian Hammer Subject: Re: Target classifications Date: Thu, 21 Sep 2006 11:50:11 +0200 X-StripMime: Non-text section removed by stripmime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mike Taylor skrev: > Per M. Hansen writes: > >>>> As you can see there are people out there who are waiting for >>>> IRSpy. :-) How is the work progeressing? >>>> >>> Looking quite nice. I'll put a copy of the web interface up on >>> test so you can see how it's coming along. >>> >> >> Sounds great, looking forward to see it. >> > > You can now see the work-in-progress at > http://irspy.indexdata.com/ > > If you get Unknown Host for that address, it's because the DNS change > hasn't propagated to you yet. Until then, make an entry in your local > hosts table pointing the hostname to 213.150.43.14 (test). > > Of course, be aware that the UI is not finished! The biggest gap at > the moment is that you can't see the results of any of the tests (at > least, not without reading the Apache logs :-) Look great, Mike. I have a few comments: * In the Add target screen I had envisioned a lot more fields for entering data about the server. First of all we need a Name field. Second it think we should have a section with additional info about the target, like URL to hosting org. Email to technical contact (that is the mail we use to send mails to when we encounter a problem with the server), Username and password, Type of library (probably a dropdown with, Academic, Public, Corporate, Special, National, Education, Other) and Country. * In the display of the targets you should have room or at least some way of showing this additional info. Maybe some kind of mouse over or popup. * In the target display, eg. under R the display of non ASCII characters goes wrong. Then I have some questions: * How are you going to handle targets that has (permanent) errors? Will they be marked or excluded from the list? * How are you going to handle email notification of technical contact persons with targets that has permanent errors? * Have you thought about a statistics page like in Z-Spy? * When added a target, can you handle targets with multiple databases? How do you write the database names in the inputbox? * When adding a new target do you have a check if the target is there already, maybe registered with the IP instead of the hostname? * Should we get a designer to give the site an overhaul? -- Per --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- From mike@miketaylor.org.uk Thu Sep 21 12:41:37 2006 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3640" "Thursday" "21" "September" "2006" "12:41:37" "+0100" "Mike Taylor" "mike@indexdata.com" nil "90" "Re: Target classifications" "^From:" nil nil "9" nil nil nil nil nil nil nil nil nil] nil) Return-Path: X-Original-To: mike Delivered-To: mike@miketaylor.org.uk Received: by localhost.localdomain (Postfix, from userid 1000) id E282CABB26; Thu, 21 Sep 2006 12:41:37 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17682.31345.810933.890051@localhost.localdomain> In-Reply-To: <45126053.701@indexdata.dk> References: <450FBF59.8270.00DD.0@sedubois.k12.in.us> <451126FB.8030005@indexdata.dk> <45112774.7070705@indexdata.dk> <17681.12470.646110.396726@localhost.localdomain> <451131CE.3040203@indexdata.dk> <17681.17678.192303.760970@localhost.localdomain> <45126053.701@indexdata.dk> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Mike Taylor To: "Per M. Hansen" Cc: Sebastian Hammer Subject: Re: Target classifications Date: Thu, 21 Sep 2006 12:41:37 +0100 Per M. Hansen writes: > > You can now see the work-in-progress at > > http://irspy.indexdata.com/ > > Look great, Mike. > > I have a few comments: Thanks for these. > * In the Add target screen I had envisioned a lot more fields for > entering data about the server. First of all we need a Name field. > Second it think we should have a section with additional info > about the target, like URL to hosting org. Email to technical > contact (that is the mail we use to send mails to when we > encounter a problem with the server), Username and password, Type > of library (probably a dropdown with, Academic, Public, Corporate, > Special, National, Education, Other) and Country. Yep, most or all of that fits into the ZeeRex record. The current version doesn't have any of it, because it's using the IRSpy ability to quietly add a new record as a side-effect of running the tests on a not-previously-known target; but when I do the proper "Add a target" page, it'll have a lot more spaces. Also, the option of uploading a pre-made ZeeRex record. > * In the display of the targets you should have room or at least > some way of showing this additional info. Maybe some kind of mouse > over or popup. Hadn't thought of those approaches -- I was just going to have a "[Details]" link. IIRC, mouseover is easy to do with compliant XHTML (which is what I use anyway) so maybe I'll try it that way. > * In the target display, eg. under R the display of non ASCII > characters goes wrong. Oh *%^$! Freakin' character-sets! :-) Thanks, I'll look into that. > Then I have some questions: > > * How are you going to handle targets that has (permanent) errors? > Will they be marked or excluded from the list? Open to discussion. The first question I suppose is what would count as "permanent" -- no response for six months? > * How are you going to handle email notification of technical > contact persons with targets that has permanent errors? Easily enough for targets whose ZeeRex records have a contact email in them! For others, I guess falling back to is the best we can do automatically? > * Have you thought about a statistics page like in Z-Spy? Patience, my pretty! > * When added a target, can you handle targets with multiple > databases? How do you write the database names in the > inputbox? In ZeeRex terms, each target is a single database -- so a Z-server that has multiple databases would register each of them as a separate target that just happens to have the same host and port as its buddies. > * When adding a new target do you have a check if the target is > there already, maybe registered with the IP instead of the > hostname? Nope. Do you think I should? > * Should we get a designer to give the site an overhaul? Given how far over time (and so over budget!) we already are, I wouldn't have thought so. But once it's all working functionally, we can revisit that and figure out what we want to do with the cosmetics. (What's wrong with it, anyway? Does it need a Hot Chick in the banner area at the top?) _/|_ ___________________________________________________________________ /o ) \/ Mike Taylor http://www.miketaylor.org.uk )_v__/\ "In JP III, scientists recreate the actual dino killer meteorite from glassy fragments found near somewhere difficult to spell in South America - evil bad people launch the meteor into space and disaster ensues" - Derek Tearne From mike Thu Sep 21 13:41:36 2006 X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil] ["4949" "Thursday" "21" "September" "2006" "14:18:09" "+0200" "Per M. Hansen" "perhans@indexdata.dk" nil "118" "Re: Target classifications" "^From:" nil nil "9" nil nil nil nil nil nil nil nil nil] nil) Return-path: Envelope-to: mike@indexdata.com Delivery-date: Thu, 21 Sep 2006 14:18:47 +0200 Received: from localhost.localdomain [127.0.0.1] by localhost.localdomain with POP3 (fetchmail-6.3.2) for (single-drop); Thu, 21 Sep 2006 13:41:36 +0100 (BST) Received: from user.indexdata.dk ([213.150.43.10] helo=[10.0.1.61]) by bagel.indexdata.dk with esmtp (Exim 4.50) id 1GQNVv-0002Os-Bq; Thu, 21 Sep 2006 14:18:47 +0200 Message-ID: <45128301.1090208@indexdata.dk> Organization: Index Data ApS User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 References: <450FBF59.8270.00DD.0@sedubois.k12.in.us> <451126FB.8030005@indexdata.dk> <45112774.7070705@indexdata.dk> <17681.12470.646110.396726@localhost.localdomain> <451131CE.3040203@indexdata.dk> <17681.17678.192303.760970@localhost.localdomain> <45126053.701@indexdata.dk> <17682.31345.810933.890051@localhost.localdomain> In-Reply-To: <17682.31345.810933.890051@localhost.localdomain> X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 213.150.43.10 X-SA-Exim-Rcpt-To: mike@indexdata.com, quinn@indexdata.dk X-SA-Exim-Mail-From: perhans@indexdata.dk X-SA-Exim-Scanned: No (on bagel.indexdata.dk); SAEximRunCond expanded to false X-UIDL: 0'=!!8Nn!!m~^!!$+="! Content-Type: text/plain; charset=ISO-8859-1; format=flowed From: "Per M. Hansen" To: Mike Taylor CC: Sebastian Hammer Subject: Re: Target classifications Date: Thu, 21 Sep 2006 14:18:09 +0200 Mike Taylor skrev: > Per M. Hansen writes: > > > You can now see the work-in-progress at > > > http://irspy.indexdata.com/ > > > > Look great, Mike. > > > > I have a few comments: > > Thanks for these. > > > * In the Add target screen I had envisioned a lot more fields for > > entering data about the server. First of all we need a Name field. > > Second it think we should have a section with additional info > > about the target, like URL to hosting org. Email to technical > > contact (that is the mail we use to send mails to when we > > encounter a problem with the server), Username and password, Type > > of library (probably a dropdown with, Academic, Public, Corporate, > > Special, National, Education, Other) and Country. > > Yep, most or all of that fits into the ZeeRex record. The current > version doesn't have any of it, because it's using the IRSpy ability > to quietly add a new record as a side-effect of running the tests on a > not-previously-known target; but when I do the proper "Add a target" > page, it'll have a lot more spaces. Also, the option of uploading a > pre-made ZeeRex record. > > > * In the display of the targets you should have room or at least > > some way of showing this additional info. Maybe some kind of mouse > > over or popup. > > Hadn't thought of those approaches -- I was just going to have a > "[Details]" link. IIRC, mouseover is easy to do with compliant XHTML > (which is what I use anyway) so maybe I'll try it that way. > > > * In the target display, eg. under R the display of non ASCII > > characters goes wrong. > > Oh *%^$! Freakin' character-sets! :-) > > Thanks, I'll look into that. > > > Then I have some questions: > > > > * How are you going to handle targets that has (permanent) errors? > > Will they be marked or excluded from the list? > > Open to discussion. The first question I suppose is what would count > as "permanent" -- no response for six months? > In Z-Spy we contact the administrator if the target is down 3 times in a row, which in praxis means 3 days in a row, and that has worked well over the years. This has to be configurable of course. In Z-Spy, we do not fall back to administrator/hostmaster/info@domain, but that is nice idea. > > * How are you going to handle email notification of technical > > contact persons with targets that has permanent errors? > > Easily enough for targets whose ZeeRex records have a contact email in > them! For others, I guess falling back to is the > best we can do automatically? > > > * Have you thought about a statistics page like in Z-Spy? > > Patience, my pretty! > Ok, just checking :-) > > * When added a target, can you handle targets with multiple > > databases? How do you write the database names in the > > inputbox? > > In ZeeRex terms, each target is a single database -- so a Z-server > that has multiple databases would register each of them as a separate > target that just happens to have the same host and port as its > buddies. > Sounds OK, but wont you get the same problem as Z-Spy, where it is very hard to display this target as one server with multiple databases under, as in one line in the display? Wouldn't you need to have each database on a new line and the user would then have to discover by her self that say line 5, 6 and 7 is actually one server with different databases. > > * When adding a new target do you have a check if the target is > > there already, maybe registered with the IP instead of the > > hostname? > > Nope. Do you think I should? > Yes, otherwise the database will get full of doubles. > > * Should we get a designer to give the site an overhaul? > > Given how far over time (and so over budget!) we already are, I > wouldn't have thought so. But once it's all working functionally, we > can revisit that and figure out what we want to do with the cosmetics. > You are probably right. > (What's wrong with it, anyway? Does it need a Hot Chick in the banner > area at the top?) > My experience is that a nice design is essential for how the customer evaluates the software. If it looks nice the software is also more likely to be evaluated as high quality. Your design is not ugly or anything but is obvious that is not something that has been spend a lot of time on, but lets keep it that way for the time being. -- Per > _/|_ ___________________________________________________________________ > /o ) \/ Mike Taylor http://www.miketaylor.org.uk > )_v__/\ "In JP III, scientists recreate the actual dino killer meteorite > from glassy fragments found near somewhere difficult to spell > in South America - evil bad people launch the meteor into space > and disaster ensues" - Derek Tearne > > >