| Time |
Nick |
Message |
| 08:29 |
|
mmorgan joined #evergreen |
| 08:42 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
mmorgan1 joined #evergreen |
| 10:53 |
|
Christineb joined #evergreen |
| 11:10 |
|
mmorgan joined #evergreen |
| 11:33 |
|
jihpringle joined #evergreen |
| 11:44 |
|
pinesol joined #evergreen |
| 12:01 |
|
mmorgan1 joined #evergreen |
| 12:57 |
Dyrcona |
Bmagic++ |
| 13:47 |
Bmagic |
Dyrcona++ |
| 14:20 |
|
BAMkubasa joined #evergreen |
| 14:22 |
BAMkubasa |
Was it an intentional decision by the Evergreen community to stick with GNU General Public License version 2 (GPLv2) rather than using the version 3 (GPLv3)? |
| 14:23 |
BAMkubasa |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=LICENSE.txt;hb=HEAD |
| 14:28 |
BAMkubasa |
(Going to post this to the mailing list) |
| 14:29 |
goood |
BAMkubasa: it's "2 or later", so you can fork and distribute as 3+, but 1) yes it was an intentional decision, and that involved lawyers at the board of regents of the university system of GA, and 2) the ship has sailed on changing that, since we do not force copyright assignment from contributors (all contributors from the beginning would have to agree to the relicensing) |
| 14:45 |
BAMkubasa |
thanks goood |
| 14:58 |
Dyrcona |
"you can fork and distribute as 3+" bit late, but it's probably not that simple. |
| 14:59 |
goood |
Dyrcona: since you've been working on the openapi server, I have something for you to consider: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/WIP-openapi_sip2_mediator ... it's a (potential, for discussion) mechanism to provide endpoints from outside the db-based config. the example endpoint is a SIP2Mediator handler. you tell it to load plugins using a space separated environment variable |
| 14:59 |
goood |
EG_OPENAPI_PLUGINS. so, `EG_OPENAPI_PLUGINS=SIP2Mediator EG_REV_PROXY_LEVELS=2 openapi_server ...` for instance. Notes: plugin endpoint sets are pondered, but not implemented; while the example show how to avoid /all/ API-specific permission restriction, adding more than the baseline API login restriction is not fleshed out (but may just work, given an appropriate security section); rate limiting is not applied to external plugin endpoints. we should |
| 14:59 |
goood |
def consider all of that before merging anything that does what the branch does |
| 15:01 |
goood |
Dyrcona: and, separately (also, jeffdavis (IIRC, you were interested in API versioning)), I have a general plan in mind for API versioning, and I'll alert here and the -dev list when I have something to show |
| 15:02 |
Dyrcona |
i am a little concerned about the use of environment variables, unless the plan is to start these subsystems via systemd. |
| 15:04 |
Dyrcona |
Interesting that the plugin defines its endpoints. |
| 16:13 |
|
jihpringle joined #evergreen |
| 16:16 |
goood |
mojo::lite makes using command line options hard. I'm actively avoiding mod_perl, since apache backends are already, like, 300MB+, so env is the easy starting point. but, like I say, this is for discussion. I'm less concerned about where the data comes from (it could come from the settings server, no problem) than I am keeping it separable. today, you could run the openapi server anywhere and tune it's local resources appropriately without having to |
| 16:16 |
goood |
think about the impact on opac, etc |
