Why would you want a CMS tool to access SMAPI when SMAPI is mostly (at least it seems to be to me) a programmable extension of Dirmaint? Why not just use Dirmaint, that is what SMAPI does in the end.
- Jason Herne On Thu, 2004-02-26 at 19:37, David Boyes wrote: > > I'm confused by the RPC+LE remark. What problems have you > > encountered? > > It's a two part problem -- neither is directly the fault of SMAPI, but both > contribute to making SMAPI difficult to use in normal, mainstream life. > > 1) Building an application to use the SMAPI is fairly complicated -- the > learning curve is quite steep. RPC programming is not exactly trivial to > understand, and it would be very nice if there was a CMS command-line > utility that allowed a user to exercise some of the less esoteric SMAPI > function without writing a C program to do it. It would definitely make > adoption of SMAPI easier and simpler, and would drive development of the > SMAPI interfaces as *the* way to interact with the system, regardless of the > underlying engine doing the assorted bit-twiddling behind the scenes. > > Right now, SMAPI is a pretty neat idea, but it is also pretty much a novelty > item -- after writing a product that attempts to exploit it, I don't think > it will catch on until/unless it is more accessible to the regular CMS user > community. I'd really like to see SMAPI incorporated into the CSL, with the > accompanying language bindings to make it more accessible, and the > abovementioned CMS utility to drive some of the more useful features. It > would also remove the prereq of licensing a C compiler just to use the > SMAPI. > > Another way to think about it is to compare it to the impact that RXSOCKET > had on the use of VM TCPIP. You released a perfectly good C socket API > library -- but how many people really exploited it until Arty Ecock loosed > his super-convenient way to exploit it on the world? Maybe someone needs to > pry Arty away from his shiny new z990 toy and get him to produce a > RXSMAPI...8-) > > 2) Distributing precompiled modules created with LE is still a pain because > of the requirement for the runtime library for C. Yes, I know about the > included LE runtime, but I still find it a support mess to deal with > multiple possible library levels at runtime and I still find occasional > differences in the licensed LE libraries and the runtime LE supplied with > z/VM. That you can't really fix (at least without taking over compiler > development for VM and reversing a long-standing trend), but it makes > exploiting function like SMAPI harder than necessary. > > Before you say it, yes I've sent in comment cards on #2. #1 is more a > enhancement request so that others need not go through what we did to get a > handle on how SMAPI works.
