[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on ARTIF-674:
----------------------------------
Can't the extension support be added without breaking compliance?
> 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
> Fix For: 2.0
>
>
> 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-674:
------------------------------
Fix Version/s: 2.0
> 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
> Fix For: 2.0
>
>
> 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Brett Meyer edited comment on ARTIF-674 at 4/9/15 11:29 AM:
------------------------------------------------------------
However, I suppose the spec is vague enough that there's no reason that we couldn't take this approach:
Maintain conformance, but in a "separated" fashion (separate Atom binding, but the "core" binding becomes JSON, etc.). We'd also maintain the /ext model for ad-hoc support, but go ahead and add the new extension plugin architecture. As long as its all *additive*, maybe it'd be worthwhile.
was (Author: brmeyer):
However, I suppose the spec is vague enough that there's no reason that we could take this approach:
Maintain conformance, but in a "separated" fashion (separate Atom binding, but the "core" binding becomes JSON, etc.). We'd also maintain the /ext model for ad-hoc support, but go ahead and add the new extension plugin architecture. As long as its all *additive*, maybe it'd be worthwhile.
> 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
> Fix For: 2.0
>
>
> 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on ARTIF-674:
-----------------------------------
However, I suppose the spec is vague enough that there's no reason that we could take this approach:
Maintain conformance, but in a "separated" fashion (separate Atom binding, but the "core" binding becomes JSON, etc.). We'd also maintain the /ext model for ad-hoc support, but go ahead and add the new extension plugin architecture. As long as its all *additive*, maybe it'd be worthwhile.
> 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Brett Meyer (JIRA)
[ 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on ARTIF-674:
-----------------------------------
> 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Eric Wittmann commented on ARTIF-674:
-------------------------------------
Also I agree with Gary - if the maintenance of the existing Atom API isn't too difficult, keeping it and adding a REST API on top would be good.
> 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on ARTIF-674:
----------------------------------
I'm all for simplifying where it makes sense.
My only concern with "loosely based on" versus "conforms to" is that RedHat makes a big deal about open standards. So if there was a way to remain compliant, while still allowing some of the simplification, then I'd prefer that.
For example, support both atom and JSON REST API - but don't put any more work than necessary into the atom binding?
> 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Eric Wittmann commented on ARTIF-674:
-------------------------------------
+1 to this - also make a list of things to ADD:
* Proper artifact type extension support - allow extensions to add custom domains, with proper schemas
> 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)
10 years, 6 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Brett Meyer (JIRA)
Brett Meyer created ARTIF-674:
---------------------------------
Summary: 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)
10 years, 6 months