RE: polling for ripe dbase software changes (fwd)
Hi Cengiz, hi David!
We would like to hear the opinion (positive or negative) of the RIPE database working group on the following proposals *before* changes are made to any of the RIPE database implementations. We might want to discuss things at the RIPE database working group session at the next RIPE meeting in Berlin.
Well, before I can develop an opinion, I'd be interested in the motivation and/or expected benefits for the proposed modifications. My first *feeling* (note, nothing more than a feeling!) is that things that belong to an external representation and a user interface should not be part of the data stored in some database. Another aspect might be multi-language support. Of coure, you can translate the syntactic sugar into syntactic salt :-) BTW, my feeling (again) with regard to the continuation stuff is that it might make sense to improve things. As it stands right now, it is not really simple to comprehend (for humans). Give me more input, then I can make up my mind. Best regards, Wilfried.
Wilfried Woeber (woeber@cc.univie.ac.at) on March 19:
Hi Cengiz, hi David!
We would like to hear the opinion (positive or negative) of the RIPE database working group on the following proposals *before* changes are made to any of the RIPE database implementations. We might want to discuss things at the RIPE database working group session at the next RIPE meeting in Berlin.
Well, before I can develop an opinion, I'd be interested in the motivation and/or expected benefits for the proposed modifications.
My first *feeling* (note, nothing more than a feeling!) is that things that belong to an external representation and a user interface should not be part of the data stored in some database. Another aspect might be multi-language support. Of coure, you can translate the syntactic sugar into syntactic salt :-)
Currently, the database software is incapable of inserting the sugar words back correctly (when the object has an error). Also, on rpsl, syntactic sugar is actually syntactic delimiters. For example: as-out: to AS1 to AS2 to AS3 announce AS4 if you omit the delimiters: as-out: AS1 AS2 AS3 AS4 which is ambigious.
BTW, my feeling (again) with regard to the continuation stuff is that it might make sense to improve things. As it stands right now, it is not really simple to comprehend (for humans).
Not by machines either. I think the line continuation rule is context sensitive, so it can not be parsed by yacc/lex in a straight forward fashion since they parse context-free languages.
Give me more input, then I can make up my mind. Best regards, Wilfried.
Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz
participants (2)
-
Cengiz Alaettinoglu
-
Wilfried Woeber, UniVie/ACOnet