[widgets] default start file table vs. src attribute
Hi all, While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a content element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] default start file table vs. src attribute
On Fri, Nov 20, 2009 at 4:58 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi all, While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a content element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? The content element is not mandatory, so you kinda need the table. Also, it needs to be specified what precedence a user agent gives to loading files, which is the second purpose of the table. The last purpose of the table is to tell a user agent what MIME type to use for each file type, which is also fairly important. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] default start file table vs. src attribute
Robin Berjon a écrit : Hi Cyril, On Nov 20, 2009, at 17:58 , Cyril Concolato wrote: While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a content element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? I actually like it, it's one less thing that we need to specify (I was unfavourable to making the configuration requires in the first place). I've implemented it and it works nicely. Yes, it's a bit of a performance hit but it's not so bad and you can cache it easily. I agree that it's not a big burden. I think it's more a question of taste. I would prefer putting more in the configuration than less. What do you mean by you can cache it easily ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] default start file table vs. src attribute
Marcos Caceres a écrit : On Fri, Nov 20, 2009 at 4:58 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi all, While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a content element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? The content element is not mandatory, so you kinda need the table. Also, it needs to be specified what precedence a user agent gives to loading files, which is the second purpose of the table. The last purpose of the table is to tell a user agent what MIME type to use for each file type, which is also fairly important. As I replied to Robin, I'd rather make it more explicit in the config file. I think it would make it more readable/understandable without requiring to know/hard-code all the default values. It's a question of taste. My suggestion was more to mandate the content element, to mandate a type attribute and to allow nesting them for indicating the precedence or use document order (multiple content elements, like the icon element). Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] default start file table vs. src attribute
On Nov 20, 2009, at 18:36 , Cyril Concolato wrote: Robin Berjon a écrit : I actually like it, it's one less thing that we need to specify (I was unfavourable to making the configuration requires in the first place). I've implemented it and it works nicely. Yes, it's a bit of a performance hit but it's not so bad and you can cache it easily. I agree that it's not a big burden. I think it's more a question of taste. I would prefer putting more in the configuration than less. Then our tastes differ :) I really think that Convention Over Configuration is the way to go here (cf http://en.wikipedia.org/wiki/Convention_over_configuration). In general, the more defaults there are, the less cases of outright failure there are, the better. Otherwise it just becomes Java programming all over again, and no one wants that, right? What do you mean by you can cache it easily ? You read the widget's configuration once, then when you read the same widget again you've cached the configuration and don't need to find the start file again (unless the locale has changed). -- Robin Berjon - http://berjon.com/
