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.
That was fast I'm still trying to get all the thought in my head on this page before starting a discussion on dev@ .
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.
2 Comments
Dan 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.
Robert Munteanu
That was fast
I'm still trying to get all the thought in my head on this page before starting a discussion on dev@ .
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.