On 12/12/2012 03:10 PM, Vojtech Szocs wrote:
> Thanks Michael, in that case we can just use XML when talking with REST API.
>
> Also, one idea worth implementing in future is to have some sort of debug
> console on GUI (I've seen this idea implemented in other applications). When
> activated, users could see REST API XML communication (request/response)
> between WebAdmin and Engine, which could be useful for someone interested in
> writing his own REST API client.
right, i always do that in all clients i've wrote (including SDKs & CLI).
>
> Vojtech
>
>
> ----- Original Message -----
> From: "Michael Pasternak" <mpast...@redhat.com>
> To: "Vojtech Szocs" <vsz...@redhat.com>
> Cc: "Itamar Heim" <ih...@redhat.com>, "engine-devel" <engine-devel@ovirt.org>
> Sent: Wednesday, December 12, 2012 1:33:56 PM
> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>
> On 12/12/2012 01:51 PM, Vojtech Szocs wrote:
>> Hi, sorry for my late response,
>>
>>>> Our first iteration could be:
>>>> a1, rewrite UiCommon (UI business logic) layer to work with API types
>>>> a2, write adapter (e.g. modify Frontend class) between UiCommon using API
>>>> types and Generic API (GWT RPC) using internal entities
>>>
>>> does this mean converting three times?
>>
>> Not sure what you mean, but here's my idea of the first iteration - what
>> would happen on frontend side (GWT):
>> 1. UiCommon, using API types, invokes query/command via RPC bridge
>> (org.ovirt.engine.ui.frontend.Frontend class)
>> 2. Frontend class, still using Generic API (GWT RPC), does the actual
>> query/command invocation
>> 3. Frontend class receives query/command result and translates it from BE
>> type to API type (converter callback)
>>
>> My idea was to isolate BE type usage into Frontend class, so that when we
>> decide to use REST API, we just need to update our RPC bridge (Frontend
>> class).
>>
>>>> Our second iteration could be:
>>>> b1, remove adapter from step a2, drop Generic API (GWT RPC) usage
>>>> b2, write API type <-> JSON mapper, possibly using some existing framework
>>>
>>> do you mean talking with api in JSON?
>>
>> Yes, that was my original idea. I'm not against using XML when talking with
>> REST API either. GWT supports parsing both JSON and XML.
>
> infra. is there, but officially we not supporting json yet,
> (resteasy-json-provider has issues with jaxb, - we waiting for fix)
>
>>
>> Vojtech
>>
>>
>> ----- Original Message -----
>> From: "Michael Pasternak" <mpast...@redhat.com>
>> To: "Vojtech Szocs" <vsz...@redhat.com>
>> Cc: "Itamar Heim" <ih...@redhat.com>, "engine-devel" <engine-devel@ovirt.org>
>> Sent: Sunday, November 25, 2012 9:27:59 AM
>> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>>
>> On 11/20/2012 12:57 PM, Vojtech Szocs wrote:
>>> Hi Michael,
>>>
>>>> if we plan moving UI on top of API, you should be:
>>>>
>>>> 1. importing restapi-types project
>>>> 2. writing intermediate layer to translate BE entities to API's using #1
>>>> 3. using public entities from #2
>>>>
>>>> this way your future migration to API (instead of native BE) will be much
>>>> more easier.
>>>
>>> Indeed, this is very useful for GWT RPC -> REST API transition in general,
>>> many thanks for pointing this out, Michael. As you suggest, we can use
>>> restapi-types mappers to translate between internal entities and API types.
>>>
>>> Our first iteration could be:
>>> a1, rewrite UiCommon (UI business logic) layer to work with API types
>>> a2, write adapter (e.g. modify Frontend class) between UiCommon using API
>>> types and Generic API (GWT RPC) using internal entities
>>
>> does this mean converting three times?
>>
>>>
>>> Our second iteration could be:
>>> b1, remove adapter from step a2, drop Generic API (GWT RPC) usage
>>> b2, write API type <-> JSON mapper, possibly using some existing framework
>>
>> do you mean talking with api in JSON?
>>
>>> b3, write RPC layer that talks REST API with Engine
>>>
>>> However, in order to use REST API types on client (GWT), we need their
>>> source code. restapi-interface-definition uses Maven JAXB plugin to
>>> generate API types from XSD schema (src/main/resources/api.xsd). On client,
>>> we need restapi-definition-<version>-sources.jar that includes those
>>> generated API types (target/generated-sources/xjc).
>>
>>>
>>> As for UI plugins (short term), we can just use restapi-types mappers and
>>> implement step b2, (API type -> JSON mapper).
>>>
>>> Thanks,
>>> Vojtech
>>>
>>>
>>> ----- Original Message -----
>>> From: "Michael Pasternak" <mpast...@redhat.com>
>>> To: "Vojtech Szocs" <vsz...@redhat.com>
>>> Cc: "Itamar Heim" <ih...@redhat.com>, "engine-devel"
>>> <engine-devel@ovirt.org>
>>> Sent: Tuesday, November 20, 2012 9:48:27 AM
>>> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>>>
>>> On 11/20/2012 12:13 AM, Itamar Heim wrote:
>>>> On 11/19/2012 02:07 PM, Vojtech Szocs wrote:
>>>>> Hi Itamar,
>>>>>
>>>>> UI plugin infrastructure translates internal business entities into
>>>>> JSON-like representations and passes those representations to UI plugins.
>>>>> (Internal entities are NOT
>>>>> exposed to UI plugins directly.)
>>>>>
>>>>> Currently, all entities supported by UI plugin infrastructure (as per
>>>>> org.ovirt.engine.ui.webadmin.plugin.entity.EntityType) are transformed
>>>>> into following representation:
>>>>>
>>>>> { entityId: "[BusinessEntityGuidAsString]" }
>>>>>
>>>>> For example, a VM entity with entity ID "vm123" will translate to:
>>>>>
>>>>> { entityId: "vm123" }
>>>>>
>>>>> Translation is currently based on
>>>>> org.ovirt.engine.core.common.businessentities.BusinessEntity interface,
>>>>> like so: "BusinessEntity<? extends NGuid>" (we expect ID type
>>>>> parameter to be NGuid-compatible). However, I've found that there are
>>>>> some entities (like Pool -
>>>>> org.ovirt.engine.core.common.businessentities.vm_pools) that don't
>>>>> implement BusinessEntity interface.
>>>>
>>>> ok, so we only pass the ID for now. good.
>>>>
>>>>>
>>>>> Quick question to backend folks - IIRC all entities extend
>>>>> org.ovirt.engine.core.common.businessentities.IVdcQueryable, but not all
>>>>> entities implement
>>>>> org.ovirt.engine.core.common.businessentities.BusinessEntity interface.
>>>>> What is the precise relation between IVdcQueryable and BusinessEntity?
>>>>>
>>>>> As for UI plugins, currently all entities get translated to above
>>>>> mentioned basic JSON-like representation. You can see the relevant code in
>>>>> org.ovirt.engine.ui.webadmin.plugin.entity.BaseEntity.from() static
>>>>> method. There's a TODO that says "make this class [BaseEntity] abstract
>>>>> and create specific entity for
>>>>> each EntityType" - this means we are planning to extend the above
>>>>> mentioned basic JSON-like representation for different entity types.
>>>>>
>>>>> For example, for a VM entity we might do:
>>>>>
>>>>> { entityId: "[BusinessEntityGuidAsString]", osType: "[VmOsType]" }
>>>>
>>>> just make sure the entity matches the REST API entity.
>>>> (which probably means entityId should be changed to id?)
>>>
>>> if we plan moving UI on top of API, you should be:
>>>
>>> 1. importing restapi-types project
>>> 2. writing intermediate layer to translate BE entities to API's using #1
>>> 3. using public entities from #2
>>>
>>> this way your future migration to API (instead of native BE) will be much
>>> more easier.
>>>
>>>>
>>>>>
>>>>> Vojtech
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Itamar Heim" <ih...@redhat.com>
>>>>> To: "Vojtech Szocs" <vsz...@redhat.com>
>>>>> Cc: "engine-devel" <engine-devel@ovirt.org>
>>>>> Sent: Friday, November 16, 2012 5:24:52 PM
>>>>> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>>>>>
>>>>> On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>>>>>>> is there a clear list of all APIs supported now?
>>>>>>
>>>>>> Not yet, unfortunately, this should be part of "for plugin developers"
>>>>>> wiki that is planned to be written in upcoming weeks.
>>>>>
>>>>> i just wanted to review how we solved not using internal entities as
>>>>> part of the API
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
