On 7/04/2010 8:26 PM, Phil Stracchino wrote: >> Oh well, I'll use it if it still works. It's not like I can't port the >> config over to whatever is required later if it is ever dropped. Thanks >> for the tip. >> >> I'm troubled by the approach taken with Bacula of "it's possible with >> some scripting, so why should Bacula make it simple and easy to do this >> common task". Then again, perhaps I'm just trying to do things the wrong >> way and what I see as simple and common, like concurrent backups to a >> sd, isn't. > > Part of what's going on is that Bacula has explored several different > routes for scriptable automation so as to provide the maximum possible > flexibility, but so far each of them has been found to have drawbacks. > (The principal drawback in the case of Python being, in my admittedly > inexpert opinion, that Python is something of a niche language, much > less widely known and used than - for example - Perl. While I know > people who swear by Python, I also know plenty who swear *at* it, not > least for its use of whitespace to define lexical scope.)
While I don't care the tiniest bit about the whitespace issue, I used to swear at Python very frequently because: - The dev team's answer to any embedding issues is "you're doing it wrong. You should rewrite your whole application as a Python module and run it under the Python interpreter, not embed the Python interpreter in your app." You can imagine how appealing THAT idea is with, say, a large Qt-based C++ GUI application... - The Global Interpreter Lock (GIL). 'nuff said. I no longer maintain Scribus's embedded scripting support and my embedded Python headaches are gone, but I'd certainly never choose it again for any embedding project when I could pick Lua or a JavaScript library instead. ( OK, that's not strictly true, it's great if your app is single-threaded and always will be, not powered by an event loop, and you want scripting users to be able to do anything without any restriction or security policy. But that's kinda rare. ) > While > different solutions have been explored at different times, generally the > original basic functionality that may be limited but works has not been > removed unless it's actively broken or causing things to break. (I'm > actually surprised that schedule-based overrides have not been removed, > given the Pool problems already discussed.) I suspect there are other use cases not covered by the pool overrides. People may need schedule-based overrides that don't neatly correspond to job levels. IMHO before they could be removed there'd need to be a way to override anything, not just pool selection, by job level. Even then it's hard to say if people would need them for other things. I guess that's what on-startup deprecation warnings are for... -- Craig Ringer ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
