apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tushar Gosavi <tus...@datatorrent.com>
Subject Re: [APEX-3/APEX-104] Module Separator.
Date Wed, 02 Dec 2015 18:00:46 GMT
Hi All,

Following are the choices for separator
Char Votes
/    3
$    3
::   3
~    1
#    1

I will '/' as a separator as it will look like as a hierarchical path in
REST api,
but need to confirm that as web framework might not support '/' character in
parameter. If there is any issue while processing REST calls, I will use '$'
as a separator.

-Tushar.

On Wed, Dec 2, 2015 at 6:04 PM, Tushar Gosavi <tushar@datatorrent.com>
wrote:

> We already have explicit check to guard against duplicate operator names.
>
> On Tue, Dec 1, 2015 at 3:41 PM, Ganelin, Ilya <Ilya.Ganelin@capitalone.com
> > wrote:
>
>> Regardless of which symbol we select, we should add an explicit run-time
>> check to guard against collisions.
>>
>>
>>
>> Thank you,
>> Ilya Ganelin
>>
>>
>>
>> -----Original Message-----
>> From: Priyanka Gugale [priyanka@datatorrent.com<mailto:
>> priyanka@datatorrent.com>]
>> Sent: Tuesday, December 01, 2015 04:01 AM Eastern Standard Time
>> To: dev@apex.incubator.apache.org
>> Subject: Re: [APEX-3/APEX-104] Module Separator.
>>
>>
>> +1 for $.
>>
>> -Priyanka
>>
>> On Tue, Dec 1, 2015 at 2:26 PM, Chandni Singh <chandni@datatorrent.com>
>> wrote:
>>
>> > I will also consider tilde  as a separator. Module1~Operator1.
>> >
>> > Less conflict and more readable.
>> >
>> > On Tue, Dec 1, 2015 at 12:22 AM, Shubham Pathak <
>> shubham@datatorrent.com>
>> > wrote:
>> >
>> > > +1 for $ or (::) double colon
>> > >
>> > > Thanks,
>> > > Shubham
>> > >
>> > > On Tue, Dec 1, 2015 at 11:11 AM, Chinmay Kolhatkar <
>> > > chinmay@datatorrent.com>
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I want to propose 2 more options for this:
>> > > > 1) $ (Dollar delimited)
>> > > > Dollar sign is usually to indicate inner classes in Java.
>> Considering
>> > > that
>> > > > I believe this can work in REST APIs and CLI as well.
>> > > >
>> > > > Hence the operator inside module can look like:
>> > > > Module1*$*Module2*$*Operator1
>> > > >
>> > > > 2) | (Pipe Delimited)
>> > > > Operator name would look like:
>> > > > Module1*|*Module2*|*Operator1
>> > > >
>> > > > 3) / (Unix File Seperator)
>> > > > This seperate is common and used in most of the places. file
>> seperator
>> > is
>> > > > also used to indicate the content inside something.
>> > > > Operator name would look like:
>> > > > Module1*/*Module2*/*Operator1
>> > > >
>> > > > If there are technical challenges in above, I would vote for (::)
>> > double
>> > > > colon.
>> > > >
>> > > > -Chinmay.
>> > > >
>> > > >
>> > > > ~ Chinmay.
>> > > >
>> > > > On Tue, Dec 1, 2015 at 11:01 AM, Tushar Gosavi <
>> tushar@datatorrent.com
>> > >
>> > > > wrote:
>> > > >
>> > > > > dot can not be used in dt-site.xml, as '.' is used as separator
>> for
>> > > > parsing
>> > > > > various component from configuration file.
>> > > > >
>> > > > > - Tushar.
>> > > > >
>> > > > > On Tue, Dec 1, 2015 at 10:48 AM, Yogi Devendra <
>> > > yogidevendra@apache.org>
>> > > > > wrote:
>> > > > >
>> > > > > > I would prefer '.' (dot).
>> > > > > > If there are some technical challenges for dot then I vote
for :
>> > > > (colon)
>> > > > > or
>> > > > > > :: (double colon) in that sequence.
>> > > > > >
>> > > > > > ~ Yogi
>> > > > > >
>> > > > > > On 1 December 2015 at 10:17, Gaurav Gupta <
>> gaurav@datatorrent.com>
>> > > > > wrote:
>> > > > > >
>> > > > > > > What about using “#”? We use this for Unifiers.
>> > > > > > >
>> > > > > > > Thanks
>> > > > > > > - Gaurav
>> > > > > > >
>> > > > > > > > On Nov 30, 2015, at 8:08 PM, Tushar Gosavi <
>> > > tushar@datatorrent.com
>> > > > >
>> > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > Hi All,
>> > > > > > > >
>> > > > > > > > As part of module support, we will need to generate
names
>> for
>> > > > > operators
>> > > > > > > > internal to the module before adding it to the
original DAG
>> to
>> > > > avoid
>> > > > > > > > conflict of names. For example if a developer
adds a
>> operator
>> > > with
>> > > > > name
>> > > > > > > "A"
>> > > > > > > > and module is name "M" in the DAG. Developer of
'M' is
>> adding a
>> > > > > > operator
>> > > > > > > > 'A' into the module DAG. To avoid name conflict
>> > > > > > > > with the operator in the main DAG we will generate
name for
>> > > > internal
>> > > > > > > > operators by concatenation of module name and
operator name.
>> > The
>> > > > 'A'
>> > > > > > > within
>> > > > > > > > module 'M' will be added to main DAG as 'M_A'.
 This works
>> for
>> > > > > > recursive
>> > > > > > > > modules too. (i.e module containing module).
>> > > > > > > >
>> > > > > > > > Which separator should we use for module namespace?
The
>> > > requirement
>> > > > > are
>> > > > > > > > - Less chances of collision. (User can add operator
with
>> name
>> > > 'M_A'
>> > > > > > too).
>> > > > > > > > - Compatible with json format. (Should not have
a problem
>> while
>> > > > > parsing
>> > > > > > > > json response from rest api)
>> > > > > > > > - Should be able to specify property in dt-site.xml.
>> > > > > > > >
>> > > > > > > > While '_' works, In the pull request it has been
pointed out
>> > that
>> > > > it
>> > > > > > has
>> > > > > > > > higher chance of collision. Few choices are
>> > > > > > > >
>> > > > > > > > 1) _ (Underscore)
>> > > > > > > > 2) __ (double underscore)
>> > > > > > > > 3) : (colon, I will check compatibility with rest
API, as
>> it is
>> > > > used
>> > > > > to
>> > > > > > > > separate key and value in json)
>> > > > > > > > 4) :: (Double colon).
>> > > > > > > > 5) Let developer choose the separator by specifying
dag
>> > property,
>> > > > but
>> > > > > > > > default is still needed.
>> > > > > > > > 6) Any other option?
>> > > > > > > >
>> > > > > > > > Please suggest which approach to take?
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > Regards,
>> > > > > > > > -Tushar.
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> ________________________________________________________
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The information
>> transmitted herewith is intended only for use by the individual or entity
>> to which it is addressed. If the reader of this message is not the intended
>> recipient, you are hereby notified that any review, retransmission,
>> dissemination, distribution, copying or other use of, or taking of any
>> action in reliance upon this information is strictly prohibited. If you
>> have received this communication in error, please contact the sender and
>> delete the material from your computer.
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message