It's definitely an interesting and smart approach, today.
I hope the following doesn't sound defensive; it's just context and
observations.
Keep in mind that my package dates back to 2012.
1. There were a half dozen AWS services. Of those few, S3 was the 90% use
case.
2. There was no API spec for machine-generation. Because 1; why bother.
For most services, the only truly tricky and difficult part is
request-signing. Most services need one core function: You give it an
HTTP request, it gives you back the signed request (or makes the signed
request and gives you back the response). You could add many little
"wrapper" functions around this. But some users would be fine just
forming the request and using the core function to sign it. Especially
for the services that just consume and excrete blobs of JSON.
So, I can imagine at least two packages for each of the ever-growing
number of AWS services:
1. A tiny core request-signing library.
2. A wrapper library. Machine-generated. It uses 1.
Some people use 2. Others just use 1 directly.
As to who will plant the seed, harvest the wheat, grind the flour, and
bake the bread: My casual opinion is that most users of AWS are
eventually paying Amazon, and, many of the newer services are especially
clearly things that commercial entities will use. As a result, I think
that one or more companies using Racket with AWS to (try to) make money,
should do and/or fund any new work in this area.
p.s. Machine-generating wrappers doesn't mean there still won't be
non-trivial work, even if "just housekeeping". For N AWS services, there
are N*2 packages to maintain. Even more if one does the {lib doc test
meta} package split. CI scripts need to be updated for new versions of
Racket. And so on.
p.p.s. Although I wouldn't object if commercial entities using my
existing package wanted to recognize my work with a donation, I also
don't mind if they don't.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/87muhmotga.fsf%40greghendershott.com.
For more options, visit https://groups.google.com/d/optout.
