[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTPAPI concerns

Scott - Thanks!
This will probably ease most if not all of their concerns...
-sjl


Scott wrote:

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:
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
----------------------------------------------------------------------- 
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------