10:09 p.m.
Itamar,
I'm actually looking forward to the portal and web admin next week. I'm
certain there will be some convergence/reusability there and it would be
helpful to see the different use cases at hand. I'm also looking at
ways to ensure
As a background, we used the RHEVM-API because of it provides us the
ability to do pretty much anything that the IE-Only GUI did. And with
fewer clicks ;-) Before that, my alternative was to fire up my Remote
Desktop application on my Xoom and pull back the windows environment -
not very android wifi friendly.
I think there are 2 design goals that are relevant here:
1) One codebase to generate a mobile application for both iOS and
Android.
2) Cache the immutable attributes for resources (GUIDs, in
particular) to the number of remote calls.
This does not preclude someone from flipping to the full browser on the
mobile device, but it can provide some quick admin functionality,
especially in when there is a poor network connection.
Isaac
On 10/27/11 2:10 PM, Itamar Heim wrote:
sorry i am late to this, but workshop preparations took their toll
this
week.
unlike rhev-m 2.2 which required a windows client, ovirt has a full web
admin based on GWT (which should work on tablets as well)
I do see a place for a UI designed more for smartphones.
I am not sure if technology (and effort) wise it will be better to
develop it separately over the REST API, or improve the ovirt web admin
and user portal to render/look better for smaller screens.
I want to be clear i am not against Nomad, but i recommend Nomad to
review the web admin and user portal ovirt has to see if a
"smartphone/tablet" mode for it wouldn't be much easier to do.
for example, the user portal and web admin share the same "UI Common"
logic code for the parts shared for them.
maybe creating another view layer on top of the same UI logic (rather
than on the REST API) would make more sense.
I'd also check if tablets are still an issue with the web admin - apart
from maybe adjusting to a little bit lower resolution, it should work as is.
I think understanding if/how the flows and look and feel are different
for this use case would be important to understand this.
would love to see some discussion on this next week.
Thanks,
Itamar
On 10/24/2011 03:11 PM, Carl Trieloff wrote:
> This vote is to include Nomad into the oVirt incubtaor. Details about
> the project can be found at
> http://www.ovirt.org/wiki/Project_Proposal_-_Nomad
>
> More information about the incubator at oVirt can be found at
> http://www.ovirt.org/governance/adding-a-subproject/
>
> In order to be accepted into the incubator, the project needs to be able
> to articulate its goals, scope and how it relates/integrates with the
> oVirt project. Nomad has done this. Entering the incubator is the low
> bar vote, which Nomad in my view clearly gets over.
>
> Note that the vote from incubator to full oVirt project (not this vote)
> is where we look for the demonstration of project criteria. The idea
> with the incubator is that any project that can articulate how it
> relates to oVirt should be able to enter the incubator and then work out
> details while in incubation.
>
> Vote open till the 27th.
>
> Here is my +1
>
> Carl.
> _______________________________________________
> Board mailing list
> Board(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
--
Isaac Christoffersen
Sr. Software Engineer, Vizuri
web: http://www.vizuri.com
--
"Tell me and I forget. Teach me and I remember. Involve me and I learn." -
Benjamin Franklin