--- Dmitry Yemanov <dimitr@...> wrote:

> "Martijn Tonies" <m.tonies@...> wrote:
> >
> > Heck, the feature has been sponsored for once - someone had
> > made a time-estimation for it ...
> >
> > But it all ended there.

As I've pointed out before, it hasn't "Ended" at all. We (DRB Systems,
Inc.) are still willing to sponsor this feature. There just doesn't
seem to be any way to make it happen. We'd even be willing to settle
for a method where we can kill an attachment and have its query(s) be
stopped (within a reasonable interval up to a few seconds). As I
understand it, we need to use separate attachments if we want to put
each report in a thread anyway, so that would work for us.)

>
> It ended because:
>
> 1) questions about API remained open
> 2) it doesn't work in classic mode

I think it ended because it's the first step off the edge of a slippery
slope. Once we started discussing the ability to kill queries, we had
to discuss the ability to figure out what query to kill, which brought
us to performance monitoring features like IB7's, which became too
large a feature to consider adding to FB 2.0.

It also ended because there's no semi-formalized method of defining
features, estimating their cost, and getting them paid for. If a
company can afford to hire a programmer to work on the project (like
Broadview and IBPhoenix do), that makes the process workable. But for a
company that wants to invest less than $20K or whatever per year to get
a few enhancements added, there's no clear way to do it.

I think this might be something the foundation can help with. That's
why I volunteered to serve on the committee. Maybe I can help define a
process where we (the foundation) can collect targeted sponsorships to
pay for features like this, and provide the oversight to get them
defined, get the definitions agreed upon, and then route the money to
the programmers to buy the time to get them built.