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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
