Re: HTTPAPI concerns

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

   Steve,
   1) As you know, Profound Logic does provide commercial support for
   HTTPAPI, and this was set up exactly for the situation you're
   describing where a company wants to have commercial support because
   they are relying on this software.  Yes, it does mean that if any
   defects are found they will be fixed.
   2) I have not made an effort to track HTTPAPI's usage.  I can tell you
   that there are more than 800 people subscribed to this mailing list,
   and the vast majority of discussion on this list is about HTTPAPI.
   Therefore, I feel reasonably safe saying there are hundreds of shops
   using it.
   At every user group or convention that I go to, I run into many people
   who are using HTTPAPI.  It's quite amazing, as at every single
   engagement, without exception, I hear from people who are happy
   customers,  This is one of the things I really enjoy about open source
   software -- people are so grateful for it, they come up and thank me,
   etc.   With commercial software, it's the opposite, we thank them for
   buying it...   but with open source, they thank me for letting them use
   it.  It feels good.
   But, no I don't have any official numbers.  I think requiring users to
   register to download the tool, and forcing them to indicate how they
   are using it really goes against the concept of "openness" that I was
   striving for.
   3)  There are lots of commercial alternatives, as Jon pointed out.   I
   won't rehash the options he pointed to, but here are other choices that
   Jon didn't mention (1) Java has always had HTTP support built-in.
   Although it's slow and cumbersome to use from RPG, it may work for
   you.   (2) In recent releases & tech refreshes,  SQL also has HTTP
   support built-in.
   My experience is that almost every other tool, however, has some
   limitations -- it makes some assumptions on how you are going to use
   HTTP, and therefore makes it difficult for you to control the finer
   details.  HTTPAPI is the most versatile that I've found...     but,
   it's entirely possible that you don't need that versatility.
   In the end, it's up to you. if you wish to use HTTPAPI, it's here, and
   I'll be quite happy if it's useful to you.   If it's not the right tool
   for you, then I wish you the best of luck with whatever you do choose.
   -SK
   On 8/5/2014 10:35 AM, Stephen Landess wrote:

   (Long-time lurker, first time posting here...)

   My client is a very large multinational company, and there are concerns
   by some about using open-source software such as FTPAPI, HTTPAPI, or
   Scott�s JDBC wrapper.
   This company is in the process of converting from JDE World software
   (running on IBM i 7.1) to SAP on another platform, and we will need to
   be able to consume web services provided by the SAP side to do some
   integrations during the transition period.

   Before my manager will approve the use of the HTTPAPI on the JDE side,
   I need to address some of those concerns.
   1) Support?
   I indicated that there is an active group of users who help support
   this program.
   However, he was more concerned about what happens if we have a program
   failure which we cannot fix internally.
   Yesterday I called Profound Logic sales and got a price quote for
   support.  They indicated that for our processor group (P30) that the
   price for support is $ 1,200.00 per year per LPAR.
   I assume this means that if we sign up with them for support that any
   defects identified in HTTPAPIR4 will be fixed.


   2) How widely is HTTPAPI used?
   I was also asked how large is the user base for HTTPAPI.

   Since HTTPAPI is limited to use on IBM i systems, there will obviously
   be a limited number of shops using it.  If this was a commercial
   package, the vendor would provide a list of references that could be
   checked.
   Is there a list of companies where HTTPAPI is in use?

   Best Regards,
   Steve Landess
   Austin, Texas


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
[1]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

References

   1. http://www.scottklement.com/mailman/listinfo/ftpapi

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------