<HTML>
<BODY>
Salvete!<br>

<br>

&gt;I don't recall that we did that specifically, although we did usually do <br>

&gt;custom templates for clients. We still should have some systems running <br>

&gt;simple acquisitions - however they don't work with the MARC stuff - my <br>

&gt;recollection is that once the MARC stuff came at 2.x acquisitions <br>

&gt;started to come unstuck because it had no "native" awareness of MARC. So <br>

&gt;it would work as long as you had MARC off - but not with MARC on. <br>

&gt;<br>

&gt;I'm guessing that with later versions it got dropped as that was too <br>

&gt;hard to reconcile as most people moved to MARC. <br>

&gt;<br>

&gt;We have some non MARC systems still running and they use simple (and <br>

&gt;possibly even some original "normal") acquisisitions. <br>

<br>

<br>

            *nod* So this would mean that it was nothing custom, it was simply an option that folks using MARC wouldn't have utilised and thought perhaps was never working. Even if it _were_ custom, and *weren't* contributed back, this is an open source project, folks are free to do that. It's nice of them to contribute things back to the main code, it's terribly helpful of them to do so, we appreciate users that chose this path the most, but if they're running it in their own Library in an altered fashion, that's their right. I'd also venture that this sort of custom experimentation is useful to the entire community in that it points to functionality that is crucial to at least one Library, which stinks to me of is possibly useful to all Libraries of that type and size.<br>

<br>

            While it would be nice for someone that commits code to shepherd that commitment ad infinitum, we do still owe them thanks for submitting it in the first place. So thank you. I know my CSI professors would point out that this is why comments exist, since there is no immortal programmer. I'd much rather welcome a well commented one time contribution than not get that sort of gift since we tie a maintenance shackle to it.<br>

<br>

             Finally, I'd again like to point out that out and out removal of functionality is not a bug solution. If it were bugged, then I as a user would like whatever bug (or more likely combination of bugs) it was fixed before something new was added to the core programme. If removal is the only option, I don't think it's asking to much to take a poll on this list instead of solely discussing things on the developer's list. <br>

<br>

              Librarians other than me are very patient. One of my favourite things to relate in terms of new features is the 27 year bookmobile feature implementation. Yes, we're waiting for it. Yes, we've not forgot this year. Do you have it yet? No? When will you have it done? It's been a while... The pickle is in telling us something will be done by a certain date and then not meeting that, OR in promising a feature that you never deliver upon, in which case we use our Awesome Powers of Nagging.<br>

<br>

Cheers,<br>

Brooke
</BODY></HTML>