Re: [Engine-devel] REST API calls from the GUI
On 02/21/2013 03:30 PM, Vojtech Szocs wrote: Hi guys, We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. why? they only have jaxb annotations which are 'must' for serialization talking with api. Actually, we *can* use JAXB-generated REST API Java types with GWT, since GWT compiler simply ignores annotations in Java sources during compilation to JavaScript. The only problem I see is REST API Java types using stuff like javax.xml.datatype.XMLGregorianCalendar - we'd have to emulate it in GWT (shouldn't be an issue). Other than that, I'd recommend using JAXB-generated REST API Java types, as they always match current REST API schema (api.xsd). As for the marshalling layer, we can't use JAXB (REST API Java SDK) with GWT, but we can still write deferred binding generator to generate mappers for XML -- Rest API Java type conversion. if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does), Yeah, with XML representation we would have to do this ourselves. On the other hand, things would be much simpler if REST API supported JSON, which is something we should consider (wait for JSON support? work with XML?) not sure we will support JSON in near future as we're blocked by underlying provider. It would be better if We can come up with a GWT REST API SDK, which is analogous Java SDK. I'd rather have JavaScript REST API SDK which we could use with GWT, this would open up new possibilities for web clients. Vojtech -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from
- Original Message - From: Michael Pasternak mpast...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Sunday, February 24, 2013 9:47:28 AM Subject: Re: [Engine-devel] REST API calls from On 02/24/2013 09:05 AM, Oved Ourfalli wrote: - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from - Original Message - From: Michael Pasternak mpast...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 20, 2013 2:56:59 PM Subject: Re: [Engine-devel] REST API calls from On 02/14/2013 11:20 AM, Doron Fediuck wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is easy as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK pros - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC thoughts? [1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context? Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api-GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that. Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well. I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine. +1, that's exactly what i've suggested to begin with. The only issue is that UI plugins and engine plugins shave different expectations from performance point of view. If UI is willing to wait for a refresh that may take too long for engine plugins, which would prefer to get the information as soon as possible without going into various communication layers which are not always needed. So again- a simple solution which enables transports layers to be replaced may serve more than one functionality in a better way. In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. I think
Re: [Engine-devel] DB Schema Reports
- Original Message - From: Eli Mesika emes...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, rhev-de...@redhat.com, in...@ovirt.org Sent: Friday, February 22, 2013 1:05:01 PM Subject: Re: [Engine-devel] DB Schema Reports - Original Message - From: Libor Spevak lspe...@redhat.com To: engine-devel@ovirt.org, rhev-de...@redhat.com, in...@ovirt.org Sent: Friday, February 22, 2013 10:02:55 AM Subject: DB Schema Reports Hi, let me announce new database schema reports based on the SchemaSpy Java library available. Thanks to infra group for support, especially to David Caro, who set up Mr. Jenkins's jobs. Great job ! +1 oVirt-Engine: http://resources.ovirt.org/dbreports/latest/engine/public/index.html oVirt-DWH: http://resources.ovirt.org/dbreports/latest/dwh/public/index.html Wiki: http://www.ovirt.org/DB_model Regards, Libor ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from
- Original Message - From: Oved Ourfalli ov...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Sunday, February 24, 2013 3:01:19 PM Subject: Re: [Engine-devel] REST API calls from - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org, a...@ovirt.org Sent: Sunday, February 24, 2013 1:20:12 PM Subject: Re: [Engine-devel] REST API calls from - Original Message - From: Michael Pasternak mpast...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Sunday, February 24, 2013 9:47:28 AM Subject: Re: [Engine-devel] REST API calls from On 02/24/2013 09:05 AM, Oved Ourfalli wrote: - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from - Original Message - From: Michael Pasternak mpast...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 20, 2013 2:56:59 PM Subject: Re: [Engine-devel] REST API calls from On 02/14/2013 11:20 AM, Doron Fediuck wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is easy as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK pros - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC thoughts? [1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context? Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api-GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that. Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will
Re: [Engine-devel] DB Schema Reports
- Original Message - From: Greg Padgett gpadg...@redhat.com To: Eli Mesika emes...@redhat.com Cc: Libor Spevak lspe...@redhat.com, engine-devel@ovirt.org, in...@ovirt.org Sent: Friday, February 22, 2013 3:35:32 PM Subject: Re: DB Schema Reports On 02/22/2013 06:05 AM, Eli Mesika wrote: - Original Message - From: Libor Spevak lspe...@redhat.com To: engine-devel@ovirt.org, rhev-de...@redhat.com, in...@ovirt.org Sent: Friday, February 22, 2013 10:02:55 AM Subject: DB Schema Reports Hi, let me announce new database schema reports based on the SchemaSpy Java library available. Thanks to infra group for support, especially to David Caro, who set up Mr. Jenkins's jobs. Great job ! +1, this will be very useful! Eli, is the great diagram you sent out in early December on the wiki as well? We should add a link to it from the wiki page below. I think that the current set of pages suggested here is already doing this job well oVirt-Engine: http://resources.ovirt.org/dbreports/latest/engine/public/index.html oVirt-DWH: http://resources.ovirt.org/dbreports/latest/dwh/public/index.html Wiki: http://www.ovirt.org/DB_model Regards, Libor ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
