ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram de Kruijff <bdekrui...@gmail.com>
Subject Re: [feedback] hurdles when working with ACE
Date Fri, 29 Jan 2016 17:51:52 GMT
On Wed, Jan 27, 2016 at 5:46 PM, Jan Willem Janssen
<janwillem.janssen@luminis.eu> wrote:
> Hi Bram,
>
>> On 26 Jan 2016, at 10:03, Bram de Kruijff <bdekruijff@gmail.com> 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
>

Mime
View raw message