[Oxygentank] [wsas-java-dev] Re: [esb-java-dev] Product Names

[Ruwan Linton]

Chatra Nakkawita wrote:
> I'm sorry but I don't think this will work. -1 from me. We have to be
> clear to the user on what implementation we are talking about, let it be
> a project home page, downloads page, tutorial, article etc
>
> I think the same theory on this mail applies to WSO2 products with
> multiple implementations . See
> https://www-lk.wso2.com/mailarchive/oxygentank/2007-February/001391.html
>   

I think products and libraries (in rampart case modules) are two things, 
Rampart is not a product, it can not do any thing by it self, it need to 
be integrated with some other product like WSAS to have a value for that.

 From the users perspective when he wants to find a library (framework 
or module) he needs to be aware of the implementation language if it has 
multiple implementations, or else he has to find the right library for 
his requirements. In case of a product like ESB or WSAS users do not 
have to worry about the implementation language at the very first stage 
rather he has to worry about the functionality and the features of the 
product.

Apart from that I don't think we can call WSAS or ESB as WSAS for Java 
or ESB for Java no longer, because both of those supports scripting 
languages as well. Actually ESB supports almost all the Scripting 
languages through BSF Engine. So if we say ESB/Java or ESB for Java that 
will associate wrong implication for our product that it is for Java 
based message mediation but actually it is more than that, you can even 
use Ruby to work with ESB.

In this case I think we should keep the product name as ESB and mention 
that ESB is implemented in Java in the ESB page and when there is a C 
implementation available we can still go with the product name ESB and 
we should clearly say that we have two implementations one using java 
and another using C and we must clearly specify the functionality 
(mostly same) of those, advantages and disadvantages of those and let 
the user select from one of those which fits in his requirements. These 
are not actually two products, rather they are two implementations of 
the same product, so we can specify the implementation language in the 
archive that the user has to download.

Finally I think we should not bind the term Java with our *product names*.

Thanks,
Ruwan.

> If we are having multiple implementations then we have to give equal
> status to all the implementations. IMO we need ti figure out now how we
> are going to call ESB Java implementation and ESB C implementation.
> These two will stand side by side, and the distinguishing factor will be
> the implementation language. How we are going to name multiple
> implementations of the same product will be a good topic for Jim and the
> business dev team to deal with as well. I think we can get some good
> feedback from Jim on this if we put this up to him at the upcoming
> meetings.
>
> Ok...don't get mad for quoting this- "Codehaus XFire is a
> next-generation java SOAP framework", so in this case we know when you
> say "Codehaus XFire" we know it is a Java framework and nothing else. If
> WSAS is not going to have any other implementations, then we can do the
> same with it. But it's important we mention the implementation eg.,
> 'WSO2 WSAS is an integrated Java Web services Platform' or something
> like that. So by default if you refer to WSAS you know it's Java
>
> What do you think?
>
> Thanks,
> Chatra
>
>
>
>
> Afkham Azeez wrote:
>
>   
>> Sanjiva Weerawarana wrote:
>>  
>>
>>     
>>> +1 from me too. So how about:
>>>
>>> WSAS
>>> ESB
>>> WSF/Java etc.
>>>
>>> When we do a C impl of ESB, we'll figure out what to call it .. maybe
>>> "ESB, C Edition".
>>>    
>>>
>>>       
>> ++1
>>
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Esb-java-dev mailing list
>> Esb-java-dev at wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
>>  
>>
>>     
>
>
>
> _______________________________________________
> Oxygentank mailing list
> Oxygentank at lists.wso2.com
> https://www-lk.wso2.com/cgi-bin/mailman/listinfo/oxygentank
>
>