airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Airavata GSoC 2013 Master Project
Date Tue, 23 Apr 2013 12:01:22 GMT
Great discussion Shameera & Subho.

Looks like you guys have a fair idea on what needs to be done, as you both state, a week or
two into GSOC, you can narrow down on design and specifications and so forth. Given there
are multiple students tackling these issues collectively, if there are hard decisions to make,
I would suggest to try two approaches in parallel and quickly pick one after a proof of concept.

Suresh

On Apr 23, 2013, at 3:43 AM, Subho Banerjee <subs.zero@gmail.com> wrote:

> Well exactly, as long as you can define standard way of communication. That
> is, you can define in advance what should be a string, array and what
> should be a integer etc. We have no problem.
> 
> So, when you look at problems, with JSON <-> XML or the other way round,
> they talk of the very general case (where you no nothing about the data you
> are converting other than it is valid XML/JSON). There are a myriad of
> problems in that case, which you pointed out.
> 
> But when there is standard, there is only one way of doing things, and not
> several. I think that is the way forward. So what I am proposing is maybe
> we all discuss and define this standard within the first week of GSoC
> starting and then actually move into coding. So as long as we work with the
> presumption that this will be done, we really dont have to worry a lot
> about this.
> 
> Cheers,
> Subho.
> 
> 
> On Tue, Apr 23, 2013 at 11:52 AM, Shameera Rathnayaka <
> shameerainfo@gmail.com> wrote:
> 
>> Hi,
>> 
>> On Tue, Apr 23, 2013 at 2:25 AM, Subho Banerjee <subs.zero@gmail.com>
>> wrote:
>> 
>>> Some of these problems are very specific to what the XML is
>> representing,
>>> it might not be an actual problem in Airavata,
>>> maybe some one more experienced with the codebase can point this out.
>>> 
>> 
>> All issues pointed out in the paper is not directly valid to our
>> conversion, I didn't list the issues actually need to address in this case
>> because thought it is worth to read that introduction part which explain
>> the all the issues we have with this conversion and give us a solid
>> background of that.
>> 
>>>   1. Anonymous values, Arrays, Implicit Typing, Character sets -- I
>> really
>>>   dont see these as problems, as long as you can agree that all parts of
>>>   airavata will treat the JSON in a standard (probably we have to define
>>>   this) way.
>>> 
>> 
>> 
>> The issue with JSON array only comes when we try to convert XML to JSON not
>> the other way. If we map with JSON, inputparameters and outputparameters in
>> the ServiceDescription.xsd will map with JSON Arrays. Therefore we need to
>> solve this issue.
>> 
>> JSON XML JSON
>> {"inputs":["test"]} --> <inputs>test<inputs>  --> {"inputs":["test"]}
  //
>> correct one
>>                           --> {"inputs":"test"}     // incorrect one
>> 
>>  2. Namespaces, Processing Instructions -- Is this required?
>> 
>>>   Are separate namespaces used in Airavata? Only place I can see this
>>> being
>>>   used is probably in the WSDL, but if we can agree on another way
>>>   of communicating registered applications' I/O parameters to the front
>>> end
>>>   (JSON based), then maybe we can work around this (minor) problem. Are
>>>   custom processing instructions to the Xbaya XML parse even used?
>>>   3. Attributes -- Again, this can be fixed easily
>>> 
>> 
>> Yes,attributes convertion will not be a big issues we can solve it. As
>> Lahiru mentioned in Hangout session namesapce handling is not a big issue
>> with Airavata.
>> 
>> 
>> 
>>> 
>>> <array name="abc">
>>>     <element>1</element>
>>>     <element>2</element>
>>>     <element>3</element>
>>>     <element>4</element>
>>> </array>
>>> 
>>> Can become
>>> 
>>> {
>>> 
>>>    abc : ['1', '2', '3', '4']
>>> 
>>> }
>>> 
>> 
>> With this example it show us we need to change the XML message format of
>> server side, which require to change the all schemas, If we are going to
>> change the schemas then we need to change the way it process it in Ariavara
>> core. We have dropped our initial major requirement, which is keep the
>> Airavata Server side as it is.
>> 
>> with this conversion we only deal with json strings, yes we can send JSON
>> request with other formats supported by JSON like boolen, null, Number
>> etc.. But there is no way to get the same JSON from XML as XML only deal
>> only with Strings. I think it is good if we can consume a this features
>> with JSON.
>> 
>> let say i need to send a integer or float to the server using JSON then
>> proper way is to send {"<name>":123.45} this will works fine but problem is
>> how we get the same output ?
>> 
>> Thanks,
>> Shameera.
>> 
>> 
>>> 
>>> 
>>> Cheers,
>>> Subho.
>>> 
>> 
>> 
>> 
>> --
>> Best Regards,
>> Shameera Rathnayaka.
>> 
>> Blog : http://shameerarathnayaka.blogspot.com/
>> 


Mime
View raw message