Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Otto Fowler
No, you are right, I miss read Matt’s suggestion. On July 7, 2017 at 14:53:02, Nick Allen (n...@nickallen.org) wrote: Otto - My original understanding from reading the JIRA was that you were suggesting have the REPL call the REST API. That is the idea that I am not fond of. I must have

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Matt Foley
Nick and Otto, Yes, I would view this as the correct solution here. Thanks, --Matt On 7/7/17, 11:50 AM, "Nick Allen" wrote: Yep, I think you are right, Matt. Create a Configuration API that is called from wherever it is needed; the REST API or a Stellar

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Nick Allen
Otto - My original understanding from reading the JIRA was that you were suggesting have the REPL call the REST API. That is the idea that I am not fond of. I must have misunderstood. My bad. On Fri, Jul 7, 2017 at 2:47 PM, Otto Fowler wrote: > This was my original

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Otto Fowler
Wait, Matt are you saying the answer is ‘neither’ and we should have a 3rd layer? That both call? On July 7, 2017 at 14:47:06, Otto Fowler (ottobackwa...@gmail.com) wrote: This was my original inclination and Casey’s as well when we spoke. I think Nick has some good points however, so I

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Otto Fowler
The issue ( if we agree that there is one ) is that we are going to face dual implementation of management type functions in both stellar and rest. *If* we think it is important to have one base API we should pick Stellar or Rest. On July 7, 2017 at 13:01:18, Nick Allen (n...@nickallen.org)

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Matt Foley
Hi all, At the risk of getting suddenly unpopular (:-) I would like to argue the other side. Architecturally I disagree with having REST invoke Stellar, or in general making Stellar the single point of contact for management functionality. Several reasons: 1. The architectural component

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Nick Allen
> Are we talking about exposing an endpoint that just executes a stellar statement? No, that is not the case AFAIK, Ryan. I see Otto's PR as more of a discussion around how to go about implementing Management-ish functionality in the REST API. I think the goal here is just to get consensus on

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Otto Fowler
Anyone else have feelings? On July 7, 2017 at 11:06:32, Nick Allen (n...@nickallen.org) wrote: Like you mentioned, Otto, I think it makes more sense to have a REST API that is backed by Stellar functions executed in a JVM. That is, the REST API simply executes the right Stellar functions in a

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-07 Thread Nick Allen
Like you mentioned, Otto, I think it makes more sense to have a REST API that is backed by Stellar functions executed in a JVM. That is, the REST API simply executes the right Stellar functions in a JVM. This makes it very simple to reuse the same implementation (Stellar functions) across

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-07-02 Thread Otto Fowler
Bump On June 13, 2017 at 00:11:52, Otto Fowler (ottobackwa...@gmail.com) wrote: I have opened METRON–994 : STELLAR Shell and management should front the METRON REST api As Stellar management functions start overlapping with the REST api, we

[DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

2017-06-12 Thread Otto Fowler
I have opened METRON–994 : STELLAR Shell and management should front the METRON REST api As Stellar management functions start overlapping with the REST api, we may want have stellar management backed by rest, and have a single main api - rest. Nick brings up an excellent point that we should