airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <>
Subject Re: Initiating GSoC Project - JSON support and JSON to XML bidirectional conversion for Airavata
Date Thu, 06 Jun 2013 13:20:39 GMT
Hash: SHA1

+1 for Amila's comments.  There has been a lot of thought put into the
current API. It still needs improvement but it is better to concentrate
on one API with requirements from many perspectives instead of branching.


On 6/6/13 9:14 AM, Amila Jayasekara wrote:
> Hi Shameera,
> The biggest disadvantage in having a separate JS API is, we have to
> maintain 2 API's (The Java API and the JS API you are going to introduce).
> So if we change one API for functionality, we have to make sure other API
> is also have that change. In the long run this will be inefficient and we
> cannot make sure both APIs are in sync functionality wise.
> We would like to maintain one API. (I hope others would also agree with me)
> Thanks
> Amila
> On Thu, Jun 6, 2013 at 12:43 AM, Shameera Rathnayaka <
>> wrote:
>> Hi Danushka,
>> Thanks for your suggestions and thoughts. we can list down all pros and
>> cons of each approach and select the best approach base on the results. As
>> Danushka has mentioned, we need to consider the effort and time too when we
>> do this selection.
>> @Lahiru, It would be very good, if we can know your point of on this too.
>> @All, you are welcome to add your thoughts on these approaches.
>> Thanks,
>> Shameera.
>> On Wed, Jun 5, 2013 at 5:42 AM, Danushka Menikkumbura <
>>> wrote:
>>> Sorry for the late reply as I have been busy with a release for the last
>>> few days.
>>> This was the plan (This is suggested as the first approach in my
>> proposal),
>>>> but to implement this we need to use java inside the JS. From developer
>>>> perspective it is not a good idea as there are difficulties to debug
>> and
>>>> lack of tooling support.
>>> I would still opt for Airavata API inside JS for the following reasons.
>>> 1. The current API has been there for a while, hence well tested and
>>> stable. Therefore the chances are very slim that you will end up
>> debugging
>>> through it for troubleshooting. If we have proper exception handling in
>> the
>>> JS, we will easily see what went wrong in the API call.
>>> 2. Writing an API from the scratch will require more time and effort to
>>> make it stable. Moreover, debugging a JS API written from the scratch
>> would
>>> be trickier than using a stable API inside it and checking for issues
>> that
>>> may occur sporadically.
>>> 3. I am not a "JS guy" but NetBeans would be a better options in terms of
>>> tooling IMO.
>>>> Great, This means there won't be any issue choosing above approach,
>> isn't
>>>> it? Could you please explain how we intend to support that with JS if
>> we
>>>> don't need a RabbitMQ JS API?.
>>> Frankly, I do not still see a need for JS API.
>>> Thanks,
>>> Danushka
>> --
>> Best Regards,
>> Shameera Rathnayaka.
>> email: shameera AT , shameerainfo AT
>> Blog :
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


View raw message