Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 01EA91049B for ; Wed, 16 Apr 2014 11:53:46 +0000 (UTC) Received: (qmail 14992 invoked by uid 500); 16 Apr 2014 11:53:45 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 14865 invoked by uid 500); 16 Apr 2014 11:53:43 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 14858 invoked by uid 99); 16 Apr 2014 11:53:43 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Apr 2014 11:53:43 +0000 Received: from localhost (HELO mail-vc0-f177.google.com) (127.0.0.1) (smtp-auth username smarru, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Apr 2014 11:53:43 +0000 Received: by mail-vc0-f177.google.com with SMTP id if17so10422650vcb.36 for ; Wed, 16 Apr 2014 04:53:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.1.97 with SMTP id 1mr1812240vel.23.1397649222198; Wed, 16 Apr 2014 04:53:42 -0700 (PDT) Reply-To: smarru@apache.org Received: by 10.52.138.241 with HTTP; Wed, 16 Apr 2014 04:53:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 07:53:42 -0400 Message-ID: Subject: Re: Airavata Thrift API Review - Experiment Object From: Suresh Marru To: dev@airavata.apache.org Content-Type: multipart/alternative; boundary=047d7b418c8b691fdb04f72791ef --047d7b418c8b691fdb04f72791ef Content-Type: text/plain; charset=UTF-8 On Tue, Apr 15, 2014 at 9:48 AM, Saminda Wijeratne wrote: > I started working on the final distribution for the client and in order to > perform verifications I added some samples. While writing the samples (i.e. > copy pasting it from elsewhere :)) I noticed that the Experiment has > following constraints, > > - An experiment input has a data type property which does not have any > relevance at the time of creating/launching > Very true, this has to be accessed during the configuration but no point passing it along. > - Compulsory to setup output of the experiment at the time of > creating/launching > This is certainly a bug. GFac should be able to fetch these details from registry/app catalog and not expect client to send them. > - Compulsory to setup scheduling information at the time of > creating/launching > This has to be optional and not mandatory. For now, since there is no scheduling knowledge in Orchestrator, we may have to send this. So I think we should live with this for now and plan to move this logic into orchestrator pretty soon. > > These make a potential 5-6 lines of code (which is actually needed to > launch the experiment) in to 20+ lines of code (even with the supporting > util classes we have introduced). Any suggestions on usability aspect on > this? > I agree we should be back to 5-6 lines. Suresh --047d7b418c8b691fdb04f72791ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 15, 2014 at 9:48 AM= , Saminda Wijeratne <samindaw@gmail.com> wrote:
I started working on t= he final distribution for the client and in order to perform verifications = I added some samples. While writing the samples (i.e. copy pasting it from = elsewhere :)) I noticed that the Experiment has following constraints,

- An experiment input has a data type property which does not have any = relevance at the time of creating/launching

Very true, this has to be accessed during the configuratio= n but no point passing it along.
=C2=A0
- Com= pulsory to setup output of the experiment at the time of creating/launching=
This is certainly a bug. GFac should be able to fet= ch these details from registry/app catalog and not expect client to send th= em.
=C2=A0
- Compulsory to setup scheduling information at the t= ime of creating/launching
This has to be o= ptional and not mandatory. For now, since there is no scheduling knowledge = in Orchestrator, we may have to send this. So I think we should live with t= his for now and plan to move this logic into orchestrator pretty soon.=C2= =A0
=C2=A0

These make a potential 5-6 lines of code (which is actually = needed to launch the experiment) in to 20+ lines of code (even with the sup= porting util classes we have introduced). Any suggestions on usability aspe= ct on this?

I agree we should be back to 5= -6 lines.

Suresh=C2=A0

--047d7b418c8b691fdb04f72791ef--