[GitHub] [geode] kohlmu-pivotal commented on issue #3049: *DO NOT MERGE* Explore building configuration REST service using Kotlin

2019-01-03 Thread GitHub
@metatype I agree. Maybe the Kotlin experiment has a more limited scope like a non-critical Geode module, this way the effect is contained. Even though, I wholeheartedly believe that some of the concepts that Kotlin embraces by default, like immutability and non-null, could benefit `geode-core`

[GitHub] [geode] kohlmu-pivotal commented on issue #3049: *DO NOT MERGE* Explore building configuration REST service using Kotlin

2019-01-03 Thread GitHub
@metatype I agree. Maybe the Kotlin experiment has a more limited scope like a non-critical Geode module, this way the effect is contained. Even though, I wholeheartedly believe that some of the concepts that Kotlin embraces by default, like immutability and non-null, could benefit `geode-core`

[GitHub] [geode] kohlmu-pivotal commented on issue #3049: *DO NOT MERGE* Explore building configuration REST service using Kotlin

2019-01-03 Thread GitHub
@Petahhh the intent of comment is to portrait that I prefer that the REST endpoint is "DUMB" and is only responsible invoking a service call. ```ConfigurationService.createRegion("name","type",attributes)``` The fact that we use a function call to create is a detail that we have leaked. One shoul

[GitHub] [geode] kohlmu-pivotal commented on issue #3049: *DO NOT MERGE* Explore building configuration REST service using Kotlin

2019-01-02 Thread GitHub
I agree with all the comments that @Bill has made. I wonder... would it not make more sense to rather treat the REST Controller as an endpoint.. rather put the login inside the controller. Why could we not have access to the ConfigurationService here? Love the idea of Kotlin coming to the front