Bradley,
I think you misunderstood me.
In old days we had one version of CGIDEV2. When Mel retiered IBM official
took CGIDEV2 over
but a "new bersion" emerged at Giovanni's homepage and became "the main
stream version."
During the time afterwards some went for the IBM version and some went for
Giovanni's version
but in fact they became quite different since we were about 10 that
contributed to Giovanni's
version while IBM's Version only changed a little and in another direction.
But people made request in various boards for both version without telling
anybody what version
the actually ran and that was actually confusing and in practice the
majority that ran Giovanni's
version couldn't help the guy's that ran on IBM's version if the question
not was very "general".
If you create your ownversion of Scott's version you create the same
scenario we had with
CGIDEV2 unless you are able to make an agreement with Scott that he will
include your changes
in his version so we still only have one version.
I include YAJL in my powerEXT Core but it is Scott's version "as is" and
Scott has been so kind
to include 2 procedures I needed in his version. And if Scott changes his
version I can easely
change my include by just replacing it.
I also include CGIDEV2 in my powerEXT Core but that is a special and
unsupported version
because I only use part of CGIDEV2 in my own powerEXT Core procedures and I
needed it
to make powerEXT Core backward compatible with my own portfolio of CGIDEV2
programs.
I could also have included HTTPAPI and MMAIL but I chose not to do so
mainly bacause there
was no technical reason to do so since HTTPAPI and MMAIL runs on top of
powerEXT Core
in the stack and not the other way around so there is no downward bindings.
Besides that
MMAIL isn't completely free and it would have required a more frequetly
update of version
due to change management.
So it is really a matter of whetether or not you project take "ownership"
of another project
by including what eventual will become a "frozen" version of another
project.
If you scale this up to e.g. node.js and NPM's imagine what chaos you could
make by having
changed modules of main stream modules included in your own project. In
prectise if you want
to expand existing modules you must become a contributer to the original
project - that is the
way to do it.
So my best advice, and it is only meant as an advice is either to build new
functionallity outside
Scotts port or talk to Scott so he includes your contribution in his
version.
On Wed, Aug 30, 2017 at 1:23 AM, Bradley Stone <bvstone@xxxxxxxxx> wrote:
On Tue, Aug 29, 2017 at 5:44 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:
Bradley,
why make changes to Scotts YAJL port instead of just making your own
procedure that saves
stdin?
Isn't that the reason we have open source? To modify and share the
changes?
If I need it, I bet someone else will in the future.
Bradley V. Stone
www.bvstools.com
GreenTools for # Slack # <https://www.bvstools.com/g4slk.html>: Easy to
use
interfaces for sending and receiving messages on Slack!
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
midrange.com
