[wsf-dev] Fwd: Naming of WSF and IGF

[Phil Hunt]

Asa,

I have copied both lists since this discussion thread applies to both  
projects.

I think we should avoid the use of Liberty or Open Liberty, or Open.   
Since the parent organization is OpenLiberty, reusing the name  
Liberty, OpenLiberty, or even Open in the "product" or "project" name  
causes repitition.  E.g. OpenLiberty OpenWSF seems a little redundant.

Looking at the WSF stuff you are building, it is a lot bigger than I  
first thought. I thought it was just the client!

Leaving the development language issue aside, it almost looks like you  
are building a "WSF Toolkit" and re-packing it into a couple of open  
source products (e.g. WSF Client, WSF Server).

I'd almost go for WSF-J Toolkit (for people re-using the code), WSF-J  
Client and WSF-J Server for customers deploying as final products.

That still seems a little dry. Going back to Chuck Mortimore's comment  
about customers buy houses and not plumbing, I'd look for a higher  
level name. I'm not sure if this is any better, but how about Trust  
Fed.   So the full name would be something like:
openLiberty TrustFed-J ToolKit
openLiberty TrustFed-J AppKit
openLIberty TrustFed-J ProviderKit

That said, now that I have typed it out, "TrustFed" seems a little  
dry.  I'd still like to see something a little open source like.  
Project Panda or something goofy like that.  ;-)

Phil Hunt
Oracle


Begin forwarded message:

> From: Asa Hardcastle <asa.openliberty at zenn.net>
> Date: March 20, 2008 12:51:59 PM PDT (CA)
> To: Phil Hunt <phil.hunt at oracle.com>
> Cc: PRATEEK MISHRA <prateek.mishra at oracle.com>
> Subject: Re: Naming of WSF and IGF
>
> Good idea Phil.  Here is a start from me:
>
> An open source ID-WSF 2.0 implementation.
>
> Objectives:
> 	* a complete XML tooling of the entire ID-WSF 2.0 specifications  
> including ID-SIS
> 	* a client library that enables any application to easily take part  
> in an existing ID-WSF environment
> 	* a basic ID-WSF WSP along with libraries that are the basis for  
> creating new ID-WSF services   (Conor's work, Sampo's work)
> 	* a pattern that enables the establishment of an ID-SIS based or ID- 
> WSF based service clients
> 	* providing multiple software language versions of the above (to  
> date we have java WSP, java WSC client lib, C based WSP and WSC)
> 	* sample service and service consumer applications
> 	* a running and available ID-WSF environment for the purposes of  
> learning and testing
>
> That said, I'd like to bring the naming discussion back onto the wsf  
> list.
>
> Could the two of you join the id-wsf list temporarily so we can do  
> this together?
>
> http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org
>
> Maybe the use of "Liberty" could work:
>
> LibertyIGF
> LibertyWSF
>
> LFrameIGF/J
> LFrameWSF/J
>
>
> talk soon,
>
> asa
>
> --
> Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib
> Tel: +1.413.429.1044 Skype: subsystem7
>
> On Mar 20, 2008, at 11:46 AM, Phil Hunt wrote:
>
>> I've been thinking about this naming business.  Before we name  
>> something, it would be nice to describe what are the "products" we  
>> are building in open source.
>>
>> For example, my understanding is that you are building the  
>> libraries a RP can use to participate in an ID-WSF system  
>> correct?   Or better, how would you describe it.
>>
>> For my part, in order to demonstrate the use of IGF, I actually  
>> have to create, and then use declarations across a set of  
>> protocols.  So I'm building an attribute services API kinda like  
>> JNDI or JDBC that allows the developers to access data.  However  
>> because of the benefits of pre-declaration, we can leave  
>> configuration out of the application code. So probably the key cool  
>> benefit of the new API is abstraction.  So if I were to describe  
>> the IGF Attr Svc API as a product I would say it:
>> * An API using layered architecture that allowing applications to  
>> access data via multiple protocols (LDAP, SAML, ID-WSF, WS-Fed,  
>> etc) without having to set special parameters for those protocol  
>> implementations at compile time.  Individual protocols are  
>> configured exclusively at deployment time.
>> * Allows use of standardized and industry vertical schemas
>> * Declarative API allows service providers to understand data and  
>> transaction requirements of an application -- a very generic client  
>> WSDL if you like.
>> * Declarative API allows for easier Privacy Impact Assessments.
>>
>> We could also run through some other thought exercises...but  
>> starting with the qualities of our products might be a good place.
>>
>> Phil Hunt
>> Oracle
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080320/fd359a30/attachment-0001.html