[
https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin....
]
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)