[jcifs] Is the work-around also the answer?

[Anand Angad Gaur]

Hi Bret,

You wrote: "if it ain't broke, don't fix it".  It's worked for 10 years, so leave it alone.

You already know that somebody (or some update process) changed something in Active Directory making it not supporting an older protocol. So ask the AD people to support the older protocol for the next 6 months and your problem is solved. By the way nobody can blame you for changes in AD if you're not responsible for that.


-----Original Message-----
From: jcifs-bounces at lists.samba.org [mailto:jcifs-bounces at lists.samba.org] On Behalf Of Bret Comstock Waldow
Sent: 24 October 2011 14:10
To: JCIFS Samba list
Subject: Re: [jcifs] Is the work-around also the answer?

On 24/10/11 13:50, Michael B Allen wrote:
> On Sun, Oct 23, 2011 at 7:15 AM, Bret Comstock Waldow <bcw1000 at yahoo.com> wrote:
>> This is Large, Huge, International Resource Company, and that's not 
>> going to happen.  Period.
>>
>> There is a project in it's early stages to replace this software with 
>> something else, but I'm not doing that, and it won't happen soon.  
>> Maybe next year, but I have my doubts.
>>
>> I'm in Support, and I'm maintaining what's there, which will/must 
>> work
>> 24/7/365 or huge amounts of money are lost.  It WILL continue for 
>> months or years from now
Hi Bret,
> Your position is unusual for such a huge and important company. The 
> solution you are using is weak, does not work well and, most 
> important, it has not been supported for years.
This is the first time I have worked in Support.  I'm used to greenfields development, where I am given a task, and I work out the best way to do it and carry it through.

This, instead, reminds me of Man-rated Space Hardware, which I worked on in an earlier incarnation of my career.  Nothing is allowed that isn't certain.  Then it was because we didn't want to kill anyone and because killing someone would mean slowing down the space program.

Now it's because of the enormous amount of value that is flowing out every minute of every day - which is paying my and several tens of thousands of other people's salaries.  This is the ultimate of "if it ain't broke, don't fix it".  It's worked for 10 years, so leave it alone.

No one changes anything unless there is a VERY good reason, and any change is a carefully choreographed large scale ballet of interdependent actions.

And any change takes a long while.  This software will be abandoned for a replacement which is in it's early planning stages, will be selected by another company, and won't likely have any of these components in it (rumour is they are targeting off-the-shelf software).

Only if there is a stoppage is there a concern, and there was one earlier this year, which was alleviated by the pre-authentication "work-around".  Now I'm tasked with looking closer - is there a problem lurking that we should know about?  Is there something that would be a better fix?  Is there something we can learn in order to know about it when the next stoppage occurs (which hopefully won't, but we lose sleep if there is - I'll be on call 24/7 if anything goes wrong).

And I can learn useful knowledge about this software - if I can get people past the idea that discussion of replacing it is of any practical value here.  It's not in my power and I'd much rather hear clarifications of what is what, and how to check on things - skills I don't have yet and could use.

>  The alternative from
> IOPLEX is the correct replacement solution for the JCIFS HTTP Filter.
> Knowing how large businesses operate, if your management understood 
> these facts
Management has already awarded a contract to replace this software. 
It's entirely out of my hands - not even in my company - and it won't happen for an absolute minimum of 6 months to the first pilot, and more likely a year or more.  It's just not relevant to my work and needs.  I need to learn about what we have now.

> Otherwise, you really are on your own in the scenario. The JCIFS HTTP 
> Filter is dead code and posts about it here are (normally) just 
> ignored.
Now, that's useful.

I'm sad because the answers I have received so far suggest you are all in a hurry to bury this, and therefore won't tell me things you might know that would help me work with this filter - which I must do.  There aren't many other sources of information about it, and I'm unhappy to think you may not tell me what you know because you want to dispose of it, rather than because you don't know useful things about it.

Regardless of how much you think badly of it, it's doing very productive service, and I need to know about it.

Your last above is useful because it helps me to build a case that the pre-authentication "work-around" might actually be the solution.  I'm unhappy to say that because it might sway people to comments that reinforce that idea just because it fits with the idea of "get rid of it" that I'm hearing, and I'd like to hear any other knowledge anyone has as well, because this software is not dead for us, and won't be for a while.

Given how fast credit dried up in 2008, and how all other initiatives went with it, I am quite comfortable predicting this software will be used for several more years, given what's about to happen in the global markets.  There are the beginnings of a plan to replace it, and I don't expect that to make much headway, because risk taking is about to disappear again, and the current software is already doing the job quite well - as long as we can keep it running.  As the markets become volatile again (and they are going to become VERY volatile again soon) management will delay, and then shelve, the plans to replace it - so the need to understand it to support it will have a long lifetime.

So finding out what I can about what could have gone wrong is of great value to all of those several tens of thousands of people who are collecting salaries because it keeps working, no matter how much it isn't the wave of the future.

Please stop telling me to abandon it and instead please help me learn about it.  Whatever you know about it is useful today to a lot of people.

Thanks,
Bret