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 Tue, 26 Jan 2016 09:03:22 GMT
Hey Jan Willem,

On Fri, Jan 22, 2016 at 3:48 PM, Jan Willem Janssen
<janwillem.janssen@luminis.eu> wrote:
> Hi community,
>
> It has been very quiet the past couple of months on the development of ACE. I
> am currently busy with picking up the last issues we need to resolve in order
> to prepare a new release of ACE (which is long overdue already).
>

Great, nice to see some action here :)

> After the release, we’d like to start working on improving ACE again. We know
> that ACE has several white spots that might impact its use for your use cases.
> Therefore, I’d love to hear your feedback on ACE: issues, abeyance's and
> hurdles you’ve come across and you like to see improved. Other ideas on what
> can be improved are welcome as well :)
>

My three cents... :)

1) OSGi Repository support

ACE is tightly coupled to it's internal and rather simplistic OBR
implementation. AFAIK it has not been updated to the OSGi Repository
specification, it uses a simple directory tree on disk and has to
fully rebuild it's index on every change. Thus you can not extend
metadata, there is no backup/restore provision and it doesn't scale
well.

So, instead of trying to fix all this, why not decouple it. Why not
let ACE be configurable to talk to any number of
organizational/upstream repositories that are already out there. For
example, there have been a number of question about nexus, but it
would also be nice to be able to link to Bnd Hub and not having to
store and manage all those standard bundles separately. Obviously we
could still keep an updated ACE OBR als a simple default.


2) Improved/pluggable storage.

As mentioned before on our lists the current  (zipped xml) storage
model is awkward. Although fully versioned it lacks tooling to work
with, has serious performance issues and has no backup/restore
provision.

Maybe improve on it and keep it as a default that does not depend on
other infra, but again I think it would be beneficial to allow ACE to
leverage existing managed infra where required. Note that this could
be local database storage, but also distributed storage in which case
servers/realys would not have to sync zipped zml over http at all!


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.


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?

grz
Bram

Mime
View raw message