Hi Suresh, Please see my comments.
On Fri, Jul 25, 2014 at 8:37 AM, Suresh Marru <[email protected]> wrote: > Lahiru, > > Glad that you took time to sink in the design and provide suggestions. I > see that all of them are hitting the similar issue, so let me respond a > summary one: > > The suggestions you have are not really the design but usability and ease > of debugging. The Id’s and modules are there so we disambiguate usage. I think these are design issues which leads the app-catalog api to really difficult to use. I am not sure how a good design becomes difficult to use or debug. > In the previous approaches (blame me) I exactly always advocated for what > you ask below and we have seen over time, serious production usage suffers > from it. For instance in a ParamChem workflow where Gaussian is wrapped in > 10 different ways, its very error prone. With current model we can minimize the documents by defining everything in same ApplicationInterface which is good but I think having unwanted module layer is also going to be error prone. > We should not push the burden onto users to do the right thing, but the > system should enforce it. Exactly, so the API should enforce it which is not enforced by introducing Ids because we can have same name 100 different hosts, applications and anything. I believe API should enforce and users will be cannot automatically do a wrong thing in the system. So we don't need extra effort for that. > As an example, if google docs uses names, imagine the commonly used terms > like “meeting notes” or resume. There are ID’s for a reason. But as a user > you never deal with ID’s. But if you use google docs API, you very well > needs to work with ID’s. > But in App catalog we do not have a scenario like this, if we create a new document it will always be something different, Ex: amber on new machine or amber on new version. We don't create amber application again and again like we create meeting notes. > > Same here, I like the other suggestion you made in a different context, > lets develop tooling to deal with debugging. IMHO, As long as API has Ids it will be still difficult to implement tooling. > And if there are UI’s to describe documents, you never work with ID’s. > Take RegisterSampleApplications as an example, I do not think you want > simper than that. There will be additional steps. But app catalog will be > register once use 1000’s of times. For this, I think its ok to spend extra > 5 minutes to register an application to make sure users use exactly what > they intend to instead of some wild card guessing. My suggestions are mainly not what to show to the end users, but what to expose in the API so it will be easy to program the UI and we do not have to put hacks in the UI if API exposes things properly. If we want to use Ids we can use internally but not expose in the API. > > Suresh > > On Jul 25, 2014, at 3:43 AM, Lahiru Gunathilake <[email protected]> wrote: > > > Hi All, > > > > I think app-catalog design is a well-thought comprehensive design and I > would like to propose following suggestions. Please correct me if I am > wrong. > > > > I think we have to minimize the complexity in app-catalog model if some > of the components are not really necessary in 99% of our scenarios. If the > corner cases are complex we shouldn't make things complex for our most > frequent scenarios. > > > > Example: I think we do not need a layer of module and I think its not > worth api dealing with whole module layer. We can simply achieve the module > layer information by giving some meaningful name for the application > Deployment document. > > Ex:Amber-1.4,Amber-1.3 > > > > I think we should remove all the Id based query because its very > difficult to program against Ids, IMHO exposing the Ids in the API is a bad > design. If someone try to create same named document in same level again we > can simply give an error without exposing Ids to the API. To achieve this > we should not allow users to create Application deployment documents before > they create its Application interface and parsing along the application > interface name. > > > > And in practice allowing users to give same names is a bad design (with > Id model we allow users to give same name) because ultimately what users > will see is set of names not the Ids, so I think we have to enforce that in > the API. I think good API should always lead users to do minimum errors. > > > > For me this is more like a tree structure and we do not have scenario of > random access. If we know all the names we should be able to get it in a > single call with all the objects in it as we do in a normal tree where data > will be stored in the leaf nodes. Currently we do lot of traversing among > different documents, these methods will be useful during scheduling but in > the case of using Experiment configuration where we specify everything > precisely we should be able to get it right away. > > > > Regards > > Lahiru > > -- > > System Analyst Programmer > > PTI Lab > > Indiana University > > -- System Analyst Programmer PTI Lab Indiana University
