Hi Martijn, > I would suggest going for OpenSocial Gadgets for the UI framework. That will > make the UI portable, every portal that supports the Gadget standard can run > them, and we are forced to make everything RESTful. Either way, deciding what > to do with the UI is not a light decision.
Just to say that I am not against opensocial per se and agreeing that is is not a light decision :) We will have to carefully evaluate wether it is a nice fit (and I personally do have some questions there but do not know enough about os yet to say anything realy sensible :). Note however that I do think opensocial would be just one of the possibly supported 'UI/application frameworks' and I do not think we should tailor the management to opensocial but rather the other way round. In other words: Yes, I agree management functions must be exposed through a RESTfull API so that an opensocial application could adapt them as easily as a wicket or android frontend would. regards, Bram ________________________________________ From: amdatu-developers-bounces at amdatu.org [amdatu-developers-bounces at amdatu.org] On Behalf Of Martijn van Berkum [[email protected]] Sent: Monday, October 11, 2010 11:44 AM To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Repository layout and build I would suggest going for OpenSocial Gadgets for the UI framework. That will make the UI portable, every portal that supports the Gadget standard can run them, and we are forced to make everything RESTful. Either way, deciding what to do with the UI is not a light decision. From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Marcel Offermans Sent: maandag 11 oktober 2010 11:38 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Repository layout and build On 11 Oct 2010, at 11:20 , Bram de Kruijff wrote: - amdatu-launcher (minimal amdatu bootstrap artifact/assembly - felix - ace agent - preferences - useradmin - ... I would make the launcher even smaller than this: just a launcher + framework implementation + management agent. Everything else we can bootstrap with the management agent. Ok, let's see how small we can get it :) I'd like to be able to bootstrap on my G1 too 8) I've already done that, and have ACE deploy the other bundles to the device. Works like a charm! - ace server With or without OBR? Not sure. Can you elaborate on that? Sure. The "default" ACE server now includes an OBR with REST API on top, so it can manage its own artifacts. I was just wondering if we want to use that, or go with a separate repository. Probably, if we want a repository that Maven can access too, we cannot use OBR only. In that case, it might be better to completely leave out the OBR bundles in ACE and create a server without it. We would then rely on a repository that provides OBR metadata as that is what ACE currently needs to use bundles (we could use something like Nexus or Artifactory for that if they can generate our metadata). With or without client UI? I'd like ACE management to be integrated into Amdatu management eventually to get a rich and consistent UI. Still, until that time the Ace UI may come in handy to get thing up and running? Agreed, but so far we don't yet have an Amdatu management UI and I would be very hesitant to simply use Felix Web Console for that as most features it contains right now are very low level (and mainly designed to manage the OSGi instance on which it runs itself, not external ones, nor multiple ones). We should probably start thinking about what kind of UI we want for Amdatu here. As a side note, we will be moving the ACE UI to Vaadin (a web toolkit built on top of GWT and well suited for the OSGi environment). That is also a nice time to start thinking about how to modularize the UI and make it extensible and embeddable. Definitely something the ACE and Amdatu projects should join forces on! :) Greetings, Marcel
