2

We have a need to FTP files that are generated by our system, so we're trying to decide whether we should spend the time to build something that meets our criteria (relatively easy, .NET has FTP functionality built in, among other more advanced libs from 3rd parties). Or if we should buy something off the shelf.

Our requirements are roughly:

  • Must be able to trigger a file send programmatically
  • Needs to retry N number of times (configurable)
  • Queryable status of FTP requests
  • Callback on completion or fail of an FTP request

I don't need to be sold on the relative simplicity of building something like that for myself. However I do want to do the due diligence of seeing what products are available ... because if something does exist that matches the requirements above, I wouldn't mind paying for it.

gnat
  • 21,442
  • 29
  • 112
  • 288
Joel Martinez
  • 289
  • 1
  • 12
  • 4
    I assume a shell script isn't enough? – Jeremy Jun 29 '11 at 14:13
  • 2
    Is there anything particularly confidential about the data in question? Might be a factor. – Jon Hopkins Jun 29 '11 at 14:15
  • 1
    How much $$ do you think it would cost to build (assuming you have the in-house expertise to do it) vs. how much would it cost to buy/license (assuming you can find a product that matches closely enough to what you want)? – FrustratedWithFormsDesigner Jun 29 '11 at 14:57
  • 1
    @Frustrated: while developing may cost more, we found more than enough business value in developing our own solution. In our product, FTPing files is critical for us. We needed reliable and accurate information about what, when, and where etc. and while there were products off the shelf that could get it done, they were not robust enough considering the importance of the role in our system. – quentin-starin Jun 29 '11 at 15:08
  • @Jeremy, yep, not enough. @Jon, yes ... confidential client data. @Frustrated ROI isn't the question. @qes, similar situation with us, FTPing itself is not a core part of our business, but communicating the data itself is. – Joel Martinez Jun 29 '11 at 15:22
  • @Joel Martinez: Please **update** the question to clarify it. Reading a comment that references other comments is hard to follow. Please just update the question and avoid commenting. – S.Lott Jun 29 '11 at 18:20
  • So is the question here "should I build or should I buy?" or "what things fit this list of requirements so I can make that decision myself?"? – Becuzz Dec 27 '16 at 18:52
  • @Becuzz this is quite an old question, but at the time I was doing due diligence in order to make that decision ... given that building something myself to do that would have been relatively easy (and in fact, it was, since I ended up just building the solution from scratch). So I guess it was closer to the second formulation of that question as I was mainly looking to see if an existing product could easily fulfill the requirements :) – Joel Martinez Dec 29 '16 at 16:42
  • 1
    @JoelMartinez Ha, didn't realize it was so old. It showed up on the homepage and I guess I forgot to check the date. – Becuzz Dec 29 '16 at 16:55

3 Answers3

4

A great comment I saw one time was "If it’s a core business function — do it yourself, no matter what.” by Joel Spolsky, when deciding either buy or outsource. If it is then you should build it so you have total control, if not then buy or outsource is an option.

This sounds like the latter.

Bill Leeper
  • 4,113
  • 15
  • 20
  • What to use is a separate question – Bill Leeper Jun 29 '11 at 15:07
  • again, don't need to be convinced of build vs. buy, am just trying to do my due diligence. – Joel Martinez Jun 29 '11 at 15:18
  • 1
    The quote you refer to is: “If it’s a core business function — do it yourself, no matter what.” by Joel Spolsky from [his article from 2001](https://www.joelonsoftware.com/2001/10/14/). I also suggest that you edit your answer to explain the quote using both elements from the article (i.e. the control over something and the incompetency factor.) – Arseni Mourzenko Dec 25 '16 at 12:58
2

SyncBackPro would handle most of that, except I think the queryable status of FTP requests.

We used to use it, but replaced it with custom code to have more control over reporting of activity. Also, it seemed to eat a lot of CPU.

If you are creating something, I would recommend Rebex FTP. It is simpler to use than the built in .Net classes, and also has more functionality. Rebex has been rock solid for us in production.

quentin-starin
  • 5,800
  • 27
  • 26
  • yeah, the queryable status/callback is a rather important feature. Will take a look at rebex if we decide to build. thanks :-) – Joel Martinez Jun 29 '11 at 15:20
0

For something simple like that, building it yourself shouldnt take too long - perhaps not much longer than integrating a 3rd party library into your app. After all, there's already FTP support available to you, as you mention. Plus it removes the dependency on a third party library (which may/may not be an issue for your project).

GrandmasterB
  • 37,990
  • 7
  • 78
  • 131