Hi Chathuri,
Here is my 2 cents,
Providing unnecessary API methods are not that good, I don't think we need
different CRUD methods for BatchQueue and ResourceJobManager etc ...
For a example, lets take BatchQueue, BtachQueue can't exist without
ComputeResource we can relay on CRUD operations of ComputeResource to add ,
delete , update BtachQueues. When ever you need to add a new BatchQueue to
a ComputeResource what you need to do is update ComputeResource with new
BatchQueue.
If we continue to introduce such an APIs, It makes our life hard to
maintain the database, as there can be lot of stale data.
Thanks,
Shameera.
On Tue, Nov 4, 2014 at 2:53 PM, Suresh Marru <sma...@apache.org> wrote:
> If we still have all the services in Airavata.API will it help the problem
> Chathuri is pointing out?
>
> Unless we break down the service handlers into multiple services and
> multi-plex them, I see less advantage in wrapping different services.
>
> Suresh
>
> On Nov 4, 2014, at 2:27 PM, Raminder Singh <raminderjsi...@gmail.com>
> wrote:
>
> > You can split it into different classes. I already tried it for workflow
> and was successful in generating services. According to me, it does not
> need thrift multiplexing but I am in process of testing as individual
> services and will let you know if i find any issues.
> >
> > In airavataAPI.thrift, i have like following and then have different
> handler class for workflow.
> >
> > service Airavata {
> >
> > }
> > service Workflow{
> >
> > }
> >
> > Please let me know if i can help to restructure
> >
> > Thanks
> > Raminder
> > On Nov 4, 2014, at 2:04 PM, Chathuri Wimalasena <kamalas...@gmail.com>
> wrote:
> >
> >> Hi Devs,
> >>
> >> Airavata API currently has lots of method since we have experiment
> related methods, app catalog related methods and workflow related methods.
> With app catalog, we have to add lots of methods related to child level
> objects since these methods are needed if we want to come up with a UI for
> app catalog.
> >>
> >> For example, we recently added methods related to ResourceJobManager,
> BatchQueue etc (these API methods may not make much sense to all). Since
> Thrift does not support multiplexing at the client level (PHP), we can't
> use that as well. Is there a better way to manage such situation ?
> >>
> >> Thanks,
> >> Chathuri
> >
>
>
--
Best Regards,
Shameera Rathnayaka.
email: shameera AT apache.org , shameerainfo AT gmail.com
Blog : http://shameerarathnayaka.blogspot.com/
