Possibly add multi request handler functionality #5

Closed
opened 2020-01-02 21:19:04 +00:00 by tgpholly · 13 comments
tgpholly commented 2020-01-02 21:19:04 +00:00 (Migrated from github.com)

Currently Revolution only allows the use of a single request handler and if more than one request handler is included in the modules then the last one that was loaded will be used.

This shouldn't be the case and either

  • All request handlers that are loaded should be used when a request is taken in
  • User should be notified that there are multiple request handlers and the server will be closed.

Either one of these options can be done or if you have your own creative solution feel free to suggest it.

Currently Revolution only allows the use of a single request handler and if more than one request handler is included in the modules then the last one that was loaded will be used. This shouldn't be the case and either - All request handlers that are loaded should be used when a request is taken in - User should be notified that there are multiple request handlers and the server will be closed. Either one of these options can be done or if you have your own creative solution feel free to suggest it.
littlemisssynth commented 2020-01-03 03:00:14 +00:00 (Migrated from github.com)

I'd say that if each request handler had flags attached to it's requests and a central module were used to detect the flag and then pass the request on to the appropriate module, may solve this problem

I'd say that if each request handler had flags attached to it's requests and a central module were used to detect the flag and then pass the request on to the appropriate module, may solve this problem
tgpholly commented 2020-01-03 03:03:39 +00:00 (Migrated from github.com)

The idea is that the the main file will be the centrepoint of it and everything else stems from it, having one required module (consoleHandler) is bad enough.

The idea is that the the main file will be the centrepoint of it and everything else stems from it, having one required module (consoleHandler) is bad enough.
littlemisssynth commented 2020-01-03 03:05:21 +00:00 (Migrated from github.com)

logically said module would only have to be loaded in scenarios where multiple request handlers are loaded

logically said module would only have to be loaded in scenarios where multiple request handlers are loaded
tgpholly commented 2020-01-03 03:06:58 +00:00 (Migrated from github.com)

Fair point actually. Could just be an optional module to enable multihandler functionality.
Still I would prefer it to be integrated into the main framework if possible.

Fair point actually. Could just be an optional module to enable multihandler functionality. Still I would prefer it to be integrated into the main framework if possible.
littlemisssynth commented 2020-01-03 03:08:32 +00:00 (Migrated from github.com)

it's an effective temporary solution and could eventually be merged into the main framework in theory.

it's an effective temporary solution and could eventually be merged into the main framework in theory.
tgpholly commented 2020-01-03 03:12:59 +00:00 (Migrated from github.com)

All in all I would like to keep existing compatibility with existing modules such as EUS, as a compromise it could be an option in the config file?

All in all I would like to keep existing compatibility with existing modules such as EUS, as a compromise it could be an option in the config file?
littlemisssynth commented 2020-01-03 03:14:35 +00:00 (Migrated from github.com)

that would work quite nicely
it may be worth updating existing modules to add compatibility

that would work quite nicely it may be worth updating existing modules to add compatibility
tgpholly commented 2020-01-03 03:17:13 +00:00 (Migrated from github.com)

Yeah, could be a case of asking the user if they would like to load in compatibility mode with multirequest disabled. Or just flat out disabling multirequest in the framework from the module.

Yeah, could be a case of asking the user if they would like to load in compatibility mode with multirequest disabled. Or just flat out disabling multirequest in the framework from the module.
tgpholly commented 2020-01-03 03:17:47 +00:00 (Migrated from github.com)

Because some can't be updated to handle stuff like this.

Because some can't be updated to handle stuff like this.
littlemisssynth commented 2020-01-03 03:18:05 +00:00 (Migrated from github.com)

that makes sense

that makes sense
tgpholly commented 2020-01-03 03:18:49 +00:00 (Migrated from github.com)

How about, if a module states it doesn't work with multireq then shutdown the server with a message saying so.

How about, if a module states it doesn't work with multireq then shutdown the server with a message saying so.
littlemisssynth commented 2020-01-03 03:19:13 +00:00 (Migrated from github.com)

that should work

that should work
tgpholly commented 2020-01-03 05:06:57 +00:00 (Migrated from github.com)

You know, thinking about it, this is a web server and it's not really needed.
The functionality could be added in a module if someone wished to have it so i'll close this.

You know, thinking about it, this is a web server and it's not really needed. The functionality could be added in a module if someone wished to have it so i'll close this.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tgpholly/Revolution#5
No description provided.