FYI: List of current proposals

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.