airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: Lot of methods in Airavata API
Date Tue, 04 Nov 2014 19:53:30 GMT
If we still have all the services in Airavata.API will it help the problem Chathuri is pointing

Unless we break down the service handlers into multiple services and multi-plex them, I see
less advantage in wrapping different services. 


On Nov 4, 2014, at 2:27 PM, Raminder Singh <> 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
> 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 <> 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

View raw message