Sling IDE toolingPage comment added by Robert MunteanuThat was fast I fully agree that we should abstract the transport behind a generic interface. And I've also considered a basic CLI tool, but for me it's not a top priority since vlt will probably cover that.
In reply to a comment by Daniel Klco:
Seems to me the best idea to handle transport would be to abstract it behind a generic interface so that we could swap it out as needed, non-JCR Sling backend providers could provide transports with their specific APIs and users could choose which one to use. From a coding perspective, this eould help us to decouple the platform specific code from the agnositic code. We could the pass handlers or listeners into update the UI as changes are made. I think we could also support of a basic command line client with the first release. This would be beneficial for advanced developers and help us to test the transport implementations.
Change Notification Preferences
View Online
|
|
- [CONF] Apache Sling > Sling IDE tooling confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... confluence
- [CONF] Apache Sling > Sling IDE tooli... Robert Munteanu (Confluence)
- [CONF] Apache Sling > Sling IDE tooli... Robert Munteanu (Confluence)
- [CONF] Apache Sling > Sling IDE tooli... Robert Munteanu (Confluence)
