That looks ugly too IMO because every mediator has to repeat the same value when its not a per-mediator choice at all.
How about giving a way name the connector at the point of associating a connector to a config? That is, treat the connectors we ship as "classes" and allow the user to create and name an "instance"? At that point they can give the version similar to the way you have indicated but then after that it becomes "kasun-twitter" or something like that. Sanjiva. On Tue, Oct 22, 2013 at 11:17 AM, Kasun Indrasiri <[email protected]> wrote: > We have tried with version embedded in to connector name and it's not > looking very elegant. However, we can modify the versioning approach such > that we only use connector name + version during the run-time only. And not > showing that as part of the connector name. So, the config looks something > similar to the following : > > <twitter.tweet .. : Default version > <twitter.tweet version="1.1">... > > > > On Sat, Oct 19, 2013 at 4:43 PM, Sanjiva Weerawarana <[email protected]>wrote: > >> One improvement possible is to allow people to give a name to a >> configured connector and use that instead (e.g. "OTJira" type thing). Next >> version stuff though .. this has to ship now. >> >> Sanjiva. >> >> >> On Wed, Oct 16, 2013 at 5:40 PM, Afkham Azeez <[email protected]> wrote: >> >>> >>> >>> >>> On Wed, Oct 16, 2013 at 12:10 PM, Manuranga Perera <[email protected]>wrote: >>> >>>> Hi, >>>> What is the final implementation of this? >>>> Do we have to type <jira_2.0 bla="xx"> every time we use the JIRA >>>> connector ? is there a way to configure the default version so we can keep >>>> on typing <jira bla="xx"> instead? >>>> >>>> This may be a subjective argument, but <jira_2.0 bla="xx"> looks ugly >>>> to me. >>>> >>> >>> Yeah, I also agree. Would be nice if there is a default version. In most >>> cases, people would use just a single version within a runtime. >>> >>> >>>> >>>> >>>> >>>> On Wed, Aug 14, 2013 at 2:29 PM, Pulasthi Supun <[email protected]>wrote: >>>> >>>>> Hi All >>>>> >>>>> I don't think making the version optional is a good idea. For cases >>>>> like twitter even though they only have one version at a given time it >>>>> would be good to reflect the version in the configuration . >>>>> >>>>> >>>>> On Wed, Aug 14, 2013 at 2:07 PM, Piyum Fernando <[email protected]>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I think we need to make version an optional parameter. >>>>>> If version is not mentioned by the user ESB should use the latest of >>>>>> the available set. >>>>>> >>>>>> As Miyuru mentioned, in twitter like cases there is no need of >>>>>> defining the version. >>>>>> Migrating from older version to a newer means adding the new >>>>>> connector to the runtime. >>>>>> No need to change the configuration unless there are any API changes. >>>>>> >>>>>> One thing that could go wrong is that he/she may assume that the >>>>> correct connector version is used by looking at the configuration since it >>>>> does not show the version of the connector currently used. >>>>> >>>>> Regards, >>>>> Pulasthi, >>>>> >>>>>> If we are going to make it optional I'm +1 for the second approach. >>>>>> >>>>>> IMO <sfdc.query version="2.0"> and <sfdc.query> is better than >>>>>> <sfdc_2.0.query > and <sfdc.query > >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 14, 2013 at 12:05 PM, Miyuru Wanninayaka <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> It depends on the type of connector. >>>>>>> >>>>>>> There are some cloud APIs which only maintains one version ( like >>>>>>> twitter ). In those cases we don't have to have versions because in a >>>>>>> given >>>>>>> time there will be only one version. >>>>>>> >>>>>>> For cases like jira, we have to have different versions as jira >>>>>>> 3,4,5 has completely different APIs. >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 14, 2013 at 11:55 AM, Manuranga Perera <[email protected]>wrote: >>>>>>> >>>>>>>> isn't updating form one version to another of same connector a >>>>>>>> common use cause (as opposed to using multiple versions)? >>>>>>>> if so naming it like "sdfc_2.0" would not be ideal for migration. >>>>>>>> >>>>>>>> -- >>>>>>>> With regards, >>>>>>>> *Manu*ranga Perera. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Miyuru Wanninayaka >>>>>>> >>>>>>> Technical Lead >>>>>>> WSO2 Inc. : http://wso2.com >>>>>>> >>>>>>> Mobile : +94 77 209 9788 >>>>>>> Blog : http://miyurudw.blogspot.com >>>>>>> Flickr : http://www.flickr.com/photos/miyuru_daminda >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Piyum Fernando >>>>>> Software Engineer >>>>>> >>>>>> Mobile: +94 77 22 93 880 >>>>>> Home: +94 31 22 75 715 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Pulasthi Supun >>>>> Software Engineer; WSO2 Inc.; http://wso2.com, >>>>> Email: [email protected] >>>>> Mobile: +94 (71) 9258281 >>>>> Blog : http://pulasthisupun.blogspot.com/ >>>>> Git hub profile: https://github.com/pulasthi >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> With regards, >>>> *Manu*ranga Perera. >>>> >>>> phone : 071 7 70 20 50 >>>> mail : [email protected] >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>** >>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>> * >>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>> >>> * >>> * >>> *Lean . Enterprise . Middleware* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 >> 650 265 8311 >> blog: http://sanjiva.weerawarana.org/ >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sanjiva Weerawarana, Ph.D. Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
