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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/board

_______________________________________________
Board mailing list
Board@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