More descriptive commands

[asimpleidea]

The reader will be updated with more descriptive commands:

• reader poll servicedirectory instead of reader servicedirectory
• reader subscribe ...
• reader watch ...

[asimpleidea]

I may be overthinking here, but I am starting to think that having descriptive commands is very good but not in this ^ way, as the users aren't supposed to know how the "reading" is done, or better put they don't care.

So instead of having a poll this watch that I am thinking of just having a cnwan-reader read this or cnwan-reader observe that (or even just watch even if we're actually polling) and not confuse people about how the thing is done.

Maybe only actual pub/sub services like kafka would have it differently -- e.g. cnwan-reader subscribe kafka --topic this -- because that's the kind of terminology a pub/sub user would expect anyways.

Feedback much appreciated for this :)

[arnatal]

I think that more descriptive commands make sense if the service registry supports multiple ways of interaction. In that case the user might have some preference on how the service registry is consumed. If there's only one way to interact with the service registry then yes, I agree there's no need to expose the low level details.

[asimpleidea]

Yes I agree. But even then the alternative method would be to have options, I.e --poll.

To be more clear, if service directory provided a way to watch changes via grpc streams, then I would have that as default and then users could opt for polling via --poll, although I would remove the polling entirely in that case tbh.

Unless they do provide some other ways to do that with "external" methods, I.e if service directory decided to provide watching via subscription to a Google pub/sub reserved topic, then in that case I would still rather have it as subscribe pubsub rather than watch servicedirectory

[ljakab]

I think consistency ("descriptive commands") makes it less necessary to consult the documentation for quick starting, and that is a good thing. Users with advanced requirements should do the work to read the docs, check the defaults, and customize behavior to their liking.

I think Alan Kay's principle (when designing the Smalltalk language) which was also picked up by Perl's author Larry Wall should be guiding us in general: "Simple things should be simple, complex things should be possible".