Is it possible that we go to the root of that and ask Siemens about their policy for whitelisting modules? I can understand that they want to keep some control over this - but if we new what process they use for that and what criteria - then perhaps we could help them in some way? In the age of social networking we should be able to find someone from Siemens - what do you think?
-- Zbyszek On Dec 2, 2007 12:06 AM, Ian Docherty <[EMAIL PROTECTED]> wrote: > > I have some first-hand knowledge that could throw some light on this. > > I was aware that Catalyst was being used within the iPlayer team, and they > were contributing many bug fixes back into Catalyst and DBIC. I was not > aware of this 'Perl on Rails' work. There again the BBC is big so it is not > surprising that one team does not always know what another team is doing. > > Catalyst is being used only for back end systems, not customer facing. The > BBC works almost exclusively on systems that publish HTML rather than > providing dynamic content. > > J. Shirley wrote: > On Dec 1, 2007 11:29 AM, Jonathan Rockway <[EMAIL PROTECTED]> wrote: > > > > > > > <snip> > > > > > I think that the 5.6 limitation was the main reason for not using > > Catalyst. > > > > > The insanity of a few of their points lead me to believe their Perl on > Rails platform is probably not ever going to go anywhere: > - "we needed to expose any SQL queries we would make so they could be > vetted by DBA's for optimization" > - "On the live environment we were told at the time we had Perl 5.6, and a > few BBC approved perl modules." > > I certainly believe that _some_ SQL queries should be optimized, or rather > the database optimized for those queries, making every query that way is > just madness. It certainly isn't extensible. > To support the BBC on this, the SQL needs to be made visible for database > optimisation, but mainly for the purpose of showing what indexes should be > put on the tables. Since it is possible to cause the generated SQL to be > output then this should be sufficient and is no reason to avoid an ORM. > > > > > The best way to tie developers hands and waste money is by giving them an > immutable whitelist of modules. I wonder how many "utility" methods are in > this framework that should be broken out into separate modules -- and in > reality, there are probably already 3 modules already doing their utility > method. People really need to get over NIH-Syndrome. > It is not a NIH Syndrome, the BBC live environment is supported and > maintained by Siemens. You would not believe the time and effort involved in > getting new modules approved and installed on the live system (I am talking > months if not years). Is it surprising the developers lose patience and > design their own ORM when they don't have any other option? The DBAs and > support teams are also frustrated at this since it makes support so much > more difficult having all these different ways of doing the same thing. > > Regards > Ian Docherty > > > _______________________________________________ > List: [email protected] > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ > Dev site: http://dev.catalyst.perl.org/ > > -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
