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
>
