On Wed, Jan 27, 2016 at 5:46 PM, Jan Willem Janssen <[email protected]> wrote: > Hi Bram, > >> On 26 Jan 2016, at 10:03, Bram de Kruijff <[email protected]> wrote: >> >> >> 1) OSGi Repository support >> […] > > Completely agree on this. > >> >> 2) Improved/pluggable storage. >> […] > > Completely agree on this. > >> >> 3) Task oriented UI (on ReST) >> […] >> IMHO the webui is way passed it's expiration date. It's non-intuitive, >> it's unreliable, it's old technology, again doesn't scale and it just >> doesn't look sexy. >> >> I would suggest to extend/improve the ReST API and build a nice modern >> web interface against that. IMHO that ui should be way more task >> oriented, support users with searches (across repositories) , actively >> guide them with respect to configuration (required/supported tags etc) >> and resolver status etc. Probably it would have different (role based) >> perspectives. > > I agree that the current UI is a bit outdated and I like the idea of a > task oriented UI. It might nicely align with our ideas of redesigning > the client (read: the four column-based model). > >> Finally, I think that in general we should focus more on >> easy-of-use-out-of-the-box. So.. documentation yes, but why don't we >> just have a number of common resource processors (zip/metatype/...) in >> there by default? > > Fair point; aside the usual suspects of metatype configuration and binary > blobs (ZIP files), what other artifacts do you see? >
Good question :) I guess I should break down my thoughts... 1) It should all work out of the box. Not having to add the rps by hand/script and having no reasonable way to determine whether that has been done. I would hope that the aforementioned repository support would allow us to simply query for bundles with the proper capability without user interaction. 2) Another concrete resource type that comes to mind is configuration properties files. Nobody likes meta-type I think that in most cases it just makes adoption more complex. 3) Other concrete resource types would probably be rather solution/framework specific, but what they typically have in common is the need to transfer resources to the target. At present this requires implementation of a custom recognizer, helper, processor... could we provide a generic "resource artifact type" to simply that? grz Bram > -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > > My world is something with Amdatu and Apache > > Luminis Technologies > Churchillplein 1 > 7314 BZ Apeldoorn > +31 88 586 46 00 > > https://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8170.94.441.B.01 >
