Re: FYI: List of current proposals
Hi David ! => => What about the WWW/WAIS interface to the database? = =I will add it to the list. It probably slipped my mind (by my software =engineer perspective) since it is not part of the database software =itself, but a separate project. = =As far as me concerned, it is a very useful addition to the database =interfaces we already have and thus should be high on our priority list =(for the new website). I think that's 2 different issues: - WWW/WAIS access to the information contained in the DB That's probably a separate project that might need some finishing touches from the DB software engineer(s) - WWW/HTML/HTTP functionality in the DB-SW package and the whois-server and whois-client That's from my point of view part of the item to include/provide means to register URLs (in some way or another) in the DB objects. But registering the URL strings itself is not a major problem (we could use a remarks field for that porpose as an interim measure - look at spt1-ripe :-), but the *access* to the objects by way of an http or whois interface is! I haven't found a trick yet to make my browser process an object as html code... For the moment I'd like to concentrate my efforts on the second aspect! David, is there a chance to meet you during the IETF to share some drinks and thoughts? Wilfried.
Quoting from Wilfried Woeber, UniVie/ACOnet's message:
Hi David !
=> => What about the WWW/WAIS interface to the database? = =I will add it to the list. It probably slipped my mind (by my software =engineer perspective) since it is not part of the database software =itself, but a separate project. = =As far as me concerned, it is a very useful addition to the database =interfaces we already have and thus should be high on our priority list =(for the new website).
I think that's 2 different issues:
- WWW/WAIS access to the information contained in the DB
That's probably a separate project that might need some finishing touches from the DB software engineer(s)
I think what is needed is just install the software on one of the NCC servers. It is also possible, as a temporary solution, to insert a link to our server which every day mirrors the RIPE-DB and creates the wais indexes.
- WWW/HTML/HTTP functionality in the DB-SW package and the whois-server and whois-client
That's from my point of view part of the item to include/provide means to register URLs (in some way or another) in the DB objects. But registering the URL strings itself is not a major problem (we could use a remarks field for that porpose as an interim measure - look at spt1-ripe :-), but the *access* to the objects by way of an http or whois interface is! I haven't found a trick yet to make my browser process an object as html code...
It is anyway needed to reformat the DB object in HTML. That is exactly what the cgi-bin in our software does. We can cooperate to port this part of software in a different context (whois ?).
For the moment I'd like to concentrate my efforts on the second aspect!
David, is there a chance to meet you during the IETF to share some drinks and thoughts?
Wilfried.
-- ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ----------
Hi Blasco,
Antonio_Blasco Bonito writes :
- WWW/WAIS access to the information contained in the DB
That's probably a separate project that might need some finishing touches from the DB software engineer(s)
I think what is needed is just install the software on one of the NCC servers. It is also possible, as a temporary solution, to insert a link to our server which every day mirrors the RIPE-DB and creates the wais indexes.
I will ask our web server people to do that as long as they don't have convincing reasons to not do this.
- WWW/HTML/HTTP functionality in the DB-SW package and the whois-server and whois-client
That's from my point of view part of the item to include/provide means to register URLs (in some way or another) in the DB objects. But registering the URL strings itself is not a major problem (we could use a remarks field for that porpose as an interim measure - look at spt1-ripe :-), but the *access* to the objects by way of an http or whois interface is! I haven't found a trick yet to make my browser process an object as html code...
It is anyway needed to reformat the DB object in HTML. That is exactly what the cgi-bin in our software does. We can cooperate to port this part of software in a different context (whois ?).
We will be happy to steal what can be stolen ;-). It looks like it is indeed better to move that functionality to the server part since the server has more information about which keys can be looked up and things like that. Furthermore, it has some other scaling advantages: Interfaces don't need to be changed (or need less changes) when the server is upgraded and the web interfaces don't need to know about possible differences between the servers that might not use the same lookup keys and the like. David K.
Antonio_Blasco Bonito <bonito@nis.garr.it> writes:
I think what is needed is just install the software on one of the NCC servers. It is also possible, as a temporary solution, to insert a link to our server which every day mirrors the RIPE-DB and creates the wais indexes.
This definitely is on the work list for the WEB site. The WEB site people will be in touch with you.
It is anyway needed to reformat the DB object in HTML. That is exactly what the cgi-bin in our software does. We can cooperate to port this part of software in a different context (whois ?).
We will happily use whatever you have. I agree with David that it is a goodidea to put it in the whoisd code. Daniel
participants (4)
-
Antonio_Blasco Bonito -
Daniel Karrenberg -
David.Kessens＠ripe.net -
Wilfried Woeber, UniVie/ACOnet