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

[Brett McDowell]

If Phil has the premise correct -- i.e. if all the WSF projects do actually
breakdown neatly into Toolkit, AppKit, and ProviderKit -- then how about..

option A:
OpenLiberty TrustFed ToolKit
OpenLiberty TrustFed AppKit
OpenLiberty TrustFed ProviderKit

option B: (I'm just throwing something out there... it seems the heart of
WSF is the concept of "my services")
OpenLiberty MyServices ToolKit
OpenLiberty MyServices AppKit
OpenLiberty MyServices ProviderKit

option C (already one vote against this from Phil, but let's just keep the
options on the table until we get a decision):
OpenLiberty OpenWSF ToolKit
OpenLiberty OpenWSF AppKit
OpenLiberty OpenWSF ProviderKit

option D: (noting one vote for this from Phil... maybe)
OpenLiberty Panda ToolKit
OpenLiberty Panda AppKit
OpenLiberty Panda ProviderKit

option E ??

But I have a meta-question... who should be making this decision anyway?  I
think with Sampo, Conor and AOL (presumably George Fletcher) signing CLA's
(any day now?) we finally have an official independent group of contributors
to take over "governance" of this project.  And since this naming does
impact the other IGF project we need to add Phil and Prateek to that list.
So maybe only Phil, Prateek, Asa, Sampo, Conor, and George need to make this
decision?  Gentlemen, are we at that point yet?

Brett McDowell | Liberty Alliance <http://www.projectliberty.org> |
vCard<http://www.ictprojects.com/Brett_McDowell_LAP.vcf>|
Calendar<http://www.google.com/calendar/hosted/ictprojects.com/embed?src=brett%40ictprojects.com&ctz=America/New_York>


On Thu, Mar 20, 2008 at 8:06 PM, Asa Hardcastle <asa.openliberty at zenn.net>
wrote:

> So to give others some context: OpenLiberty/J turns out to be a little
> short sighted.   Since OpenLiberty has numerous projects, to which we are
> now adding regularly, we need to find a name that does not confuse this
> point.  So we are back in the naming game.
>
> It may or may not be useful for us to have a convention across all
> projects. There is certainly something to be said for continuity.  So, any
> ideas?
>
> Phil has made it clear that he does not like the idea of using "open" or
> "liberty" in the names, and has built an argument for this in the email I am
> responding too.
>
> asa
>
>
>
> --
> Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib
> Tel: +1.413.429.1044 Skype: subsystem7
>
>
>
> On Mar 20, 2008, at 4:53 PM, Phil Hunt wrote:
>
> 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
>
>
>
>
>
> _______________________________________________
> Wsf-dev mailing list
> Wsf-dev at lists.openliberty.org
>
> http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org
>
>
>
> _______________________________________________
> Igf-dev mailing list
> Igf-dev at lists.openliberty.org
>
> http://lists.openliberty.org/mailman/listinfo/igf-dev_lists.openliberty.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080322/1be29b71/attachment.html