[overlord-issues] [JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec

[Brett Meyer (JIRA)]

    [ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057405#comment-13057405 ] 

Brett Meyer edited comment on ARTIF-674 at 4/9/15 11:27 AM:
------------------------------------------------------------

> For example, support both atom and JSON REST API - but don't put any more work than necessary into the atom binding?

Thats actually a really good point.  The server-side logic is now all separated from the Atom RESTEasy code, so theoretically, adding an additional JSON binding would be fairly trivial.  We'd still get some of the benefits, especially allowing the shell, java client, and UI to use the JSON binding...

On the other hand, what Eric brings up is also a good point.  I have a *long* queue of issues on the spec's JIRA.  The extension support and several others really need corrected.  Without them, it's somewhat limiting.


was (Author: brmeyer):
> For example, support both atom and JSON REST API - but don't put any more work than necessary into the atom binding?

Thats actually a really good point.  The server-side logic is now all separated from the Atom RESTEasy code, so theoretically, adding an additional JSON binding would still be fairly trivial.  We'd still get some of the benefits, especially allowing the shell, java client, and UI to use the JSON binding...

On the other hand, what Eric brings up is also a good point.  I have a *long* queue of issues on the spec's JIRA.  The extension support and several others really need corrected.  Without them, it's somewhat limiting.

> Separate from the S-RAMP spec
> -----------------------------
>
>                 Key: ARTIF-674
>                 URL: https://issues.jboss.org/browse/ARTIF-674
>             Project: Artificer
>          Issue Type: Task
>            Reporter: Brett Meyer
>            Assignee: Brett Meyer
>
> For 2.0, we might consider separating from the S-RAMP spec.  IMO, the spec should be largely considered dead and abandoned.  RH seems to be the only entity still "using" it.  Further, many pieces are starting to hold things back, in addition to adding needless complexity.  Instead of focusing on conformance, use only "the good parts".  Claim that the project is "loosely based on S-RAMP".
> Ideas:
> REMOVE
> - Atom binding: Instead, use pure JSON REST
> - The web UI services: With the server services using JSON REST, we'd no longer need an additional service layer specifically for the web UI.
> - All "s-ramp" namespaces
> KEEP
> - Model schemas and bindings.
> - Query core syntax



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)