Should I commit AWS access SDK as contrib/hbaws ?

[Pritpal Bedi]

Hi All

As I had announced a couple of years back that I want to commit this library in Harbour contrib repository and most of you objected to the idea, I am asking again. 

It is a pure PRG code and depends on hbssl and hbtip. This implementation does not contain all the classes AWS mainstream SDK's are heaving. I worked on the following AWS services but with limited methods:

SES - Simple Email Service

SNS - Simple Notofication Service ( special emphasis on SMS relay methods )

SQS - Simple Queue Service

S3   -  Simple Storage Service

EFS - Elastic File System

STS - Security Token Service

EC2 - Elastic Compute Cloud

DynamoDB - A open-ended database servoce

Textract - Text Processing Service

Rekognition - Image Processing Services

Since the building blocks to access AWS services are there it will far easier to implement classes as and when you need them.

Looking for positive response this time.

Pritpal Bedi

a student of software analysis & concepts

[Bacco]

I really think this would be useful in a separate repo.

I think we have a fair share of not so up-to-date contribs (not saying it's your

case, it's just that even mantained, it willan extra burden to get and sync for all

Hb users that have no interest in AWS services, and it would represent an extra

focus of other devs, even if you mantain it yourself - perhaps one day you focus

on another thing and no other mantainers want to keep up the job).

I believe mantaining in a separate repo also will benefit from a fast development

pace for interested users, and will suffer less restrictions. Also, if it's pure PRG,

a separate repo will allow for easier usage without the need to use the main

repo build system. Users can mix and match their specific needs easily.

It worked better with HBQt, it seems same case here.

It's just my opinion, I'm by no means any authority here.

Best regards and thanks for your continued efforts

Bacco

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-devel/019e41fb-0d29-45f9-9d42-37a1cc7ec2bcn%40googlegroups.com.

[Alexandre Cavalcante Alencar]

Hello Pritpal,

I work with AWS SDKs/CLI on a daily basis... implementing the basis of the extensive API is a huge piece of work, especially considering the APIs and SDKs are in constant updates.

I would say a wrapper into the AWS SDK for C++[1] would be something way simple to maintain and keep up? It has the added benefit that you don't have to solve the problems that have already been solved. SDK License is Apache 2.0.

[1] https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/welcome.html

[2] https://aws.amazon.com/apache-2-0/

Bests

Alexandre Alencar
Twitter @alexandreitpro

http://blog.alexandrealencar.net/
http://www.alexandrealencar.net/

http://www.alexandrealencar.com

http://www.servicosdeti.com.br/

COBIT, ITIL, CSM, LPI, MCP-I

[Francesco Perillo]

Hi Pritpal,

I think that we should move to a npm/nuget/cargo style for contribs/addons. Just keep a minimum amount in the main package and then all the others should move to separate repositories.

My 2 cents, of course.

Francesco

[Lorenzo Fiorini]

On 18/10/2022 10:55, Francesco Perillo wrote:

> Hi Pritpal,
> I think that we should move to a npm/nuget/cargo style for
> contribs/addons. Just keep a minimum amount in the main package and
> then all the others should move to separate repositories.

That would be great.

Other "less ideal" solutions I see are:

1 - at this point one more contrib would not harm much and since AWS
support could be useful to the project we should be grateful to Pritpal
and ask him to upload it to the actual contrib folder.

2 - create an harbour/contrib repo and move there ALL the contribs. This
solution would not help a lot since probably there are 0 developers that
can use Harbour without at least one contrib but at least it'll make the
core repo REALLY CORE.

3 - move each contrib to a separate repo inside https://github.com/harbour.

Options 2 and 3 would probably make the setup more complicate since it
would require several separate downloads and probably changes to the
actual build scripts but if there are volunteers for the tasks they
could be not so hard.

Regards,
Lorenzo

[Lailton Fernando Mariano]

It is a really nice idea.

from harbour/core you can have a sub module getting the contrib. this way all will be like this but in a repo separated and leave it like really CORE.

+1