Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Services framework thoughts #51

Closed
seghcder opened this issue Jun 28, 2017 · 3 comments
Closed

Services framework thoughts #51

seghcder opened this issue Jun 28, 2017 · 3 comments

Comments

@seghcder
Copy link

Some thoughts as i was integrating a new service. Not sure if you would prefer these as individual issues or if this is ok to add to backlog (if you agree of course :-) )...

  • Differentiate user vs system services (Wikipedia vs REST)?
  • Manage service "connection" status (during init or if service becomes available / unavailable later)
  • Could the user query what services are "available" / connected?
  • Common authorisation model for services?
  • Common service name / description that can be included in the response when the user asks "What services are available"
  • Common help response if the user asks "HELP Servicename"
  • Should there just be one interface (ask_question) from the AIML side, or allow multiple so that there might be several AIML<>service interface points per "class"

Cheers

Sean

@keiffster
Copy link
Owner

Answers to each

  • Differentiate user vs system services (Wikipedia vs REST)?
    KS - What would be the purpose of the differentiation ?

  • Manage service "connection" status (during init or if service becomes available / unavailable later)
    KS - The service class should maintain its own connection status and provide appropriate retry options, plus default response if down.

  • Could the user query what services are "available" / connected?
    KS - Certainly possible, would need its own grammar and probably an extension to list the services in configuration.
    KS - In terms of available/connected, could extend the service interface with a ping() or health() method that could be called to get current status from a grammar

  • Common authorisation model for services?
    KS - Not sure as there is no common authorisation model. Some might use OAuth, others userid/password, others HTTP headers. However this may require a way to store better configuration information in the service definition - More work required here and I would be interested to see how your implementation pushes this forward

  • Common service name / description that can be included in the response when the user asks "What services are available"
    KS - Probably the same as ping()/health(), implement an info() method which returns a well defined information object

  • Common help response if the user asks "HELP Servicename"
    KS - I would push this into the grammar as thats the best place to store answers to questions. I would just create a servicename.aiml file with pattern HELP servicename

  • Should there just be one interface (ask_question) from the AIML side, or allow multiple so that there might be several AIML<>service interface points per "class"
    KS - Tough one as that would require a level of modification to the sraix tag implementation and some identification of the method to call.

@seghcder
Copy link
Author

seghcder commented Jul 6, 2017

User vs system services - I think I misunderstood the REST service as the REST client. Now I understand there are two REST oriented parts. One is the REST Client and another the Generic REST Service. Now makes sense.

By authorisation model, I meant more within ProgramY itself. At the moment Program Y assumes that if you can reach it, you can use it. In a SkypeForBusiness enterprise context, I need to check that the user connecting -

  • Is a known user and is allowed to use the bot
  • Is permitted to use all or only some services
  • Is a super-user who can ask questions like who is connected to the bot right now, service online/offline commands, send a message to all connected users, or even tell the bot to quit gracefully.

Will post another topic on this, but I wonder if this is more a "discussion" topic vs an issue topic? Not sure what the best forum in Github for these :-)

@seghcder
Copy link
Author

seghcder commented Jul 6, 2017

Rest all makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants