[wsf-dev] wsf-dev Digest, Vol 2, Issue 3: Some Decision Making
Asa Hardcastle
asa.openliberty at zenn.net
Mon Feb 5 11:24:55 EST 2007
The predominant notion was that DOM over SAX was the preferred choice
for a number of reasons, so, as far as I'm concerned, DOM is the
choice we are going with for the moment.
I'd prefer using Eclipse & ANT, I don't believe there will be
anything that is done in the code that will prevent contributers from
using their own IDE & build tool. javac & vi should be completely
fine, as I imagine NetBeans, IntelliJ IDEA, and others should be fine
- as long as everyone is using subversion properly.
Does anyone have an objection to Eclipse/ANT?
The thing that comes to mind that we need to grapple with is what
libraries and tools will we use for processing the XML/SOAP. From
what I understand OpenSAML has an XML tooling layer that could save
us a great deal of time. Are there any ideas on this? Scott made
it clear that his code keeps the DOM intact (or at least makes it
possible to add water and have it back) as well as produces java
objects for general consumption. Scott, where is this in terms of
development? Is it ready to use?
One of my major concerns is making sure that coders have access at as
many levels as possible, from a simple set of factory classes to
touching all of the underpinnings. I also feel that we should limit
the number of external libraries that we reference.
later,
asa
--
Asa Hardcastle, Technical Lead, openLiberty
Tel: +1.413.429.1044 Skype: subsystem7
On Feb 5, 2007, at 10:55 AM, Curtis Jones wrote:
> Asa et al:
>
> I had to bail early on Friday's meeting. The minutes suggest that
> there was
> an effort to make some decisions at the wrap-up of the meeting
> (e.g., DOM,
> Eclipse/Ant, SOAP, etc.) -- but if any decisions were made, it's not
> entirely clear in the minutes. Are we waiting for more detailed
> user/usage
> profiles before making these decisions?
>
> Thanks,
>
> - Curtis
>
>
> -----Original Message-----
> From: wsf-dev-bounces at openliberty.org
> [mailto:wsf-dev-bounces at openliberty.org] On Behalf Of
> wsf-dev-request at openliberty.org
> Sent: Saturday, February 03, 2007 12:00 PM
> To: wsf-dev at openliberty.org
> Subject: wsf-dev Digest, Vol 2, Issue 3
>
> Send wsf-dev mailing list submissions to
> wsf-dev at openliberty.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openliberty.org/mailman/listinfo/wsf-dev
> or, via email, send a message with subject or body 'help' to
> wsf-dev-request at openliberty.org
>
> You can reach the person managing the list at
> wsf-dev-owner at openliberty.org
>
> When replying, please edit your Subject line so it is more specific
> than
> "Re: Contents of wsf-dev digest..."
>
>
> Today's Topics:
>
> 1. OSIRIS from Spain (Asa Hardcastle)
> 2. Minutes from Meeting of 2-Feb-2006 (Eric Tiffany)
> 3. Re: Minutes from Meeting of 2-Feb-2006 (Asa Hardcastle)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 2 Feb 2007 17:00:18 -0500
> From: Asa Hardcastle <asa.openliberty at zenn.net>
> Subject: [wsf-dev] OSIRIS from Spain
> To: wsf-dev at openliberty.org
> Message-ID: <2FF589D9-4A0C-4CC4-8BCE-A205A6D26E3E at zenn.net>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
>
> Here are the links that Ajay and Diego referred to this morning
>
> talk later,
>
> asa
>
> --
> Asa Hardcastle, Technical Lead, openLiberty
> Tel: +1.413.429.1044 Skype: subsystem7
>
>
>> Hi Asa,
>>
>> this mail is on behalf of Diego Lopez and myself. We would like to
>> confirm that we'll gladly join today's conference call.
>>
>> In RedIRIS ( http://www.rediris.es/index.en.html )we are highly
>> interested in openliberty and hopefully will contribute to it with
>> code on some profiles, which we will develop for another project
>> called OSIRIS ( http://www.itea-osiris.org ).
>>
>> OSIRIS aims to create an open source infrastructure that handles the
>> full lifecycle of services in an heterogeneus environment. Being
>> security a key issue, we will provide OSIRIS partners with a WSF
>> layer
>> to interoperate with other federations.
>>
>> Also we will follow discussions on the design of the library.
>>
>> Thanks,
>>
>> Ajay Daryanani
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.openliberty.org/pipermail/wsf-dev/attachments/
> 20070202/0adee78a
> /attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Fri, 02 Feb 2007 18:11:00 -0500
> From: Eric Tiffany <eric at projectliberty.org>
> Subject: [wsf-dev] Minutes from Meeting of 2-Feb-2006
> To: <wsf-dev at openliberty.org>
> Message-ID: <C1E92F34.1CBD6%eric at projectliberty.org>
> Content-Type: text/plain; charset="US-ASCII"
>
> These minutes are included with the original agenda, though the
> conversation
> didn't really always follow that outline. See if you have any
> corrections
> --- these will be posted on the wiki, too, I expect.
>
>
> AGENDA:
> + + + + + + + + + + +
>
> 1. Introductions
>
>
> 2. Who's here, who wants to contribute?
>
> * Asa Hardcastle - all code in Java - likes chickens - implementer for
> WSC. Great Barrington MA
>
> * Ajay Daryanani Arjandas & Diego Lopez - Red Iris - Spanish national
> research network, like Internet2 - connecting universities and
> network centers - Spain - Working with digital ids for 5-6 yrs -
> planning to implement some liberty protocol - working with other
> European partners (Ericsson, Norwegian govt)
>
> * "me" Conor Cahill - conor.p.cahill at intel.com - Intel - Virginia -
> working in liberty since founded
>
> * Davis McPherson - available to help with software architecture,
> design, and dev -- worked in liberty with epok - maryland - paying
> job not involved in identity -
>
> * George Fletcher - AOL - TEG rep - Virginia - haven't been involved
> much in liberty -- ARCHITECTURE
>
> * Scott Cantor: OSU, running SSO infrastructure, contracted to
> Internet2. Working on SAML/Liberty since 2002.
>
> * Derrick Harcey - Sun - Global presales team - Create demonstration
> platforms - host those demonstrations - Dallas
>
> * Curtis Jones - software entrepreneur with telecom background -
> western
> mass
>
> * Teri Sigl - Sun - Dallas Texas - similar to Derrick, focus on
> telcomm
>
> * Scott Cantor - Internet2 Shiboleth - Ohio State university SSO -
> open saml, original author involved in liberty since 2002 --
> ARCHITECTURE
>
> * Eric Tiffany - minute taker
>
> * Brett McDowell - employee of liberty alliance - western mass
>
>
>
> 3. Tools at our disposal
>
> a. wsf-dev list
> phase 1: discuss and design on the list
> address questions like:
>> audience(s) - use cases
>> implementation priorities, initial features to support - based on use
> case
>> technologies (dependencies? Short term/long term)
> Selecting an XML platform/design on which to build the ID-
> WSF layer
>> code style guide, contributor guidelines b. wiki capture the work
> we're doing
>
> c. forum
> non architects and designers to ask questions as they see progress.
>
> d. hosted implementations (test harness)
> - open source
> - commercial
> * HP is providing an HP Select Federation evaluation version
>
> e. sourceforge
> - svn / cvs
>
> Asa: dev list should be a pretty active forum. Wiki is more for
> historical
> record of different design decisions. The forum is for questions from
> outside the project. Hosted implementations could be either
> commercial or
> oss, particularly SSO imples.
>
> Scott: confirms svn appropriate choice. Davis: concurs
>
> Conor: offers RCS
>
> Asa: asks if anyone has a platform to
>
> Derrick: actually 3 different Sun products that could be tested
> against.
>
> Asa: having SSO bootstrap may enhance adoption
>
> Scott: may be able to contribute some resources
>
> 4. Progress going forward:
>
> a. Iteratively building an architecture document & project plan
> on the
> wiki - possibly beginning with a generic outline
> - any suggestions for the generic outline? What about the OPF(open
> process framework)?
>
> b. Once the document exists, we can start writing the code based
> on the
> spec priorities. i.e. - baseline sec mech
>
> c. First objective post documentation will be a bare bones
> ClientLib with
> a demonstration app
>
>
> Asa: interested in architecture?
>
> Conor, Davis, affirmative
>
> Scott: Interested in architecture to the extent that it will mesh
> with his
> existing tooling
>
> Scott: experience is that nothing works together due to difference
> in XML
> stack between different projects. Layering to keep abstraction
> clean is very
> labor intensive and isn't worth it.
>
> Asa: libraries that keep themselves open turn out to be used but
>
> Scott: App layer is able to be more abstract than system layer
>
> Conor: Do we use DOM model or use a Java model that uses serialized
> objects
> when necessary
>
> Scott: can cache the DOM and be more efficient every time you need
> to sign
> or perform other ops that require serialization
>
> Scott: try to insulate users from sigs and serialization, but at
> the lower
> level you still need to
>
> Conor: you end up designing as a set of setters and getters against
> object
> model
>
> Scott: sort of, actually more of marshalling and unmarshalling so
> that when
> you need the DOM you reconstitute it
>
> Asa: important to have access to lower levels, but have a higher
> level api
> that can avoid complexity.
>
> Asa: need for DOM is mainly sigs, and mentioned in Wash meeting
> (what was
> that date?)
>
> Scott: security was designed with streaming in mind, but SAML
> doesn't lend
> itself for SAX based approach and Apache tried to build SAX
> canonicalizer
> into xml security stuff and found it was hard.
>
> Asa: DOM uses more memory, but easier to get going
>
> Scott: Annoys the Mobile guys, but if you are using Java on a phone
> don't
> worry about it (too big anyway)
>
> Asa: What is the audience? In terms of data size?
>
> Scott: large data is like multi-megabytes
>
> Conor: yeah, you negotiate the connection and protocol in SOAP but the
> actual data (like AOLradio) is a binary protocol
>
> Asa: like the idea of making the initial negotiation using SOAP,
> and then
> moving to another stream
>
> Conor: but the first step should be trying to contact the established
> services (eg profile service). Another thing is to invoke the
> Disco service
> which is also a first step.
>
> Asa; envisioned a sequential approach, SSO, followed by DISCO,
> followed by
> Service invoke
>
> Conor: has C++ that knows how to invoke services
>
> Asa: can you send a pointer to the piece of code
>
> Conor: offers to walk through the code with Asa
>
>
> Asa: what should be the process going forward. Architecture doc is
> Asa's
> responsibility, but he wants to get best input from the callers and
> the list
>
> Brett: do you want to build the arch dynamically on wiki?
>
> Asa: wiki isn't totally wonderful, but it's the best tool available
>
> Asa: the other option is to write a document and distribute
>
> Scott: never written an arch doc, only code!
>
> Asa: can get very detailed in a arch doc, but doesn't envision
> something
> that detailed. Break into components, so that can be changed
> incrementally.
> Compares to radio station where planning on the wiki diminishes
> enthusiasm
>
> Scott: well you are lucky if you get anyone to write documentation
> you are
> lucky. But the wiki reduces the need to continue to reinvent
> documentation.
>
> Asa:
>
> Scott: but what you really need is interfaces ,not architecture.
> Developers can work from that and avoid stepping on each other.
>
> Asa: should we do API first
>
> Scott: no, but you need to get there unless there are only 1 or 2
> people
> working
>
> Asa: the pitch will also get more people involved. Need to have more
> compelling scenario than the beer-and-pizza scenario
>
> Diego: several use cases are interesting (email sent to Asa will be
> forwarded)
>
> Asa: since we are starting from the wiki, perhaps and outline
> (objectives,
> ....). There are maybe pieces that some people take for complete
> granted,
> and we need to capture those.
>
> Brett: need to enumerate the questions we need to answer before we
> get going
> (DOM vs. SAX)
>
> Conor: whether we need to run in a Jakarta or AXIS or ?
>
> Scott: SOAP stack (or even having one).
>
> Asa: WSDL issue didn't have a solution in Washington?
>
> Scott: that's why the soap stack decision is important
>
> Brett: are we able to answer some of these qs now?
>
> Eric: DOM seemed to be consensus
>
> Scott: but perhaps the Wash discussion noted that you don't get too
> many
> signed responses, so there may not be an initial need to validate
> sigs. The
> transport usually securs the response.
>
> Conor: there is a slight hook in Disco that might use sigs, but not
> typical
>
> Scott: there have been use cases discussed where the security of the
> Server->client might use SAML (and signing) but it hasn't been
>
> Scott: Apache needs a DOM
>
> Asa: The timeline of the project, and the simplicity, plus signing,
> seems to
> indicate DOM.
>
> Brett: is there any discomfort with that
>
> Conor: Key is that the programmers are working with objects at a
> level above
> DOM
>
> Scott: DOM is not a fun API to work with at the app layer.
>
> Scott: needs to be addressed on list:
> JDK version we're targeting:
> decisions on java libraries: endorse xerxes from apache. and
> bouncy castle.
> java development environment:
>
> Ajay / Diego:
> eclipse and ant
> crypto - bouncy castle
>
> Brett:
> take a look at the Identity Landscape page on the wiki, started by
> Gerald
> Beuchelt http://www.openliberty.org/wiki/index.php/Identity_Landscape
>
> !! Weekly design discussion, status updates.
> Thursday as a design meeting 8am, PST
> 2/2/07 4:46 PM
> Every Thursday at 8am PST we will be having a dev meeting until
> things are
> under way
>
> --
> ____________________________________________________
> Eric Tiffany | eric at projectliberty.org
> Interop Tech Lead | +1 413-458-3743
> Liberty Alliance | +1 413-627-1778 mobile
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 2 Feb 2007 20:24:43 -0500
> From: Asa Hardcastle <asa.openliberty at zenn.net>
> Subject: Re: [wsf-dev] Minutes from Meeting of 2-Feb-2006
> To: Eric Tiffany <eric at projectliberty.org>
> Cc: wsf-dev at openliberty.org
> Message-ID: <9CA450EF-C339-4C96-B757-B26463E7975D at zenn.net>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Thanks Eric, these look good. If anyone feels they've been mis-
> minuted, please send corrections, but I'd like to accept and post to
> the site.
>
> asa
>
> --
> Asa Hardcastle, Technical Lead, openLiberty
> Tel: +1.413.429.1044 Skype: subsystem7
>
>
> On Feb 2, 2007, at 6:11 PM, Eric Tiffany wrote:
>
>> These minutes are included with the original agenda, though the
>> conversation
>> didn't really always follow that outline. See if you have any
>> corrections
>> --- these will be posted on the wiki, too, I expect.
>>
>>
>> AGENDA:
>> + + + + + + + + + + +
>>
>> 1. Introductions
>>
>>
>> 2. Who's here, who wants to contribute?
>>
>> * Asa Hardcastle - all code in Java - likes chickens - implementer
>> for
>> WSC. Great Barrington MA
>>
>> * Ajay Daryanani Arjandas & Diego Lopez - Red Iris - Spanish national
>> research network, like Internet2 - connecting universities and
>> network centers - Spain - Working with digital ids for 5-6 yrs -
>> planning to implement some liberty protocol - working with other
>> European partners (Ericsson, Norwegian govt)
>>
>> * "me" Conor Cahill - conor.p.cahill at intel.com - Intel - Virginia -
>> working in liberty since founded
>>
>> * Davis McPherson - available to help with software architecture,
>> design, and dev -- worked in liberty with epok - maryland - paying
>> job not involved in identity -
>>
>> * George Fletcher - AOL - TEG rep - Virginia - haven't been involved
>> much in liberty -- ARCHITECTURE
>>
>> * Scott Cantor: OSU, running SSO infrastructure, contracted to
>> Internet2. Working on SAML/Liberty since 2002.
>>
>> * Derrick Harcey - Sun - Global presales team - Create demonstration
>> platforms - host those demonstrations - Dallas
>>
>> * Curtis Jones - software entrepreneur with telecom background -
>> western
>> mass
>>
>> * Teri Sigl - Sun - Dallas Texas - similar to Derrick, focus on
>> telcomm
>>
>> * Scott Cantor - Internet2 Shiboleth - Ohio State university SSO -
>> open saml, original author involved in liberty since 2002 --
>> ARCHITECTURE
>>
>> * Eric Tiffany - minute taker
>>
>> * Brett McDowell - employee of liberty alliance - western mass
>>
>>
>>
>> 3. Tools at our disposal
>>
>> a. wsf-dev list
>> phase 1: discuss and design on the list
>> address questions like:
>>> audience(s) - use cases
>>> implementation priorities, initial features to support - based on
>> use case
>>> technologies (dependencies? Short term/long term)
>> Selecting an XML platform/design on which to build the ID-
>> WSF layer
>>> code style guide, contributor guidelines
>> b. wiki
>> capture the work we're doing
>>
>> c. forum
>> non architects and designers to ask questions as they see progress.
>>
>> d. hosted implementations (test harness)
>> - open source
>> - commercial
>> * HP is providing an HP Select Federation evaluation version
>>
>> e. sourceforge
>> - svn / cvs
>>
>> Asa: dev list should be a pretty active forum. Wiki is more for
>> historical record of different design decisions. The forum is for
>> questions from outside the project. Hosted implementations could be
>> either commercial or oss, particularly SSO imples.
>>
>> Scott: confirms svn appropriate choice. Davis: concurs
>>
>> Conor: offers RCS
>>
>> Asa: asks if anyone has a platform to
>>
>> Derrick: actually 3 different Sun products that could be tested
>> against.
>>
>> Asa: having SSO bootstrap may enhance adoption
>>
>> Scott: may be able to contribute some resources
>>
>> 4. Progress going forward:
>>
>> a. Iteratively building an architecture document & project plan on
>> the wiki - possibly beginning with a generic outline
>> - any suggestions for the generic outline? What about the OPF
>> (open
>> process framework)?
>>
>> b. Once the document exists, we can start writing the code based on
>> the spec priorities. i.e. - baseline sec mech
>>
>> c. First objective post documentation will be a bare bones
>> ClientLib with a demonstration app
>>
>>
>> Asa: interested in architecture?
>>
>> Conor, Davis, affirmative
>>
>> Scott: Interested in architecture to the extent that it will mesh
>> with
>> his existing tooling
>>
>> Scott: experience is that nothing works together due to difference in
>> XML stack between different projects. Layering to keep abstraction
>> clean is very labor intensive and isn't worth it.
>>
>> Asa: libraries that keep themselves open turn out to be used but
>>
>> Scott: App layer is able to be more abstract than system layer
>>
>> Conor: Do we use DOM model or use a Java model that uses serialized
>> objects when necessary
>>
>> Scott: can cache the DOM and be more efficient every time you need to
>> sign or perform other ops that require serialization
>>
>> Scott: try to insulate users from sigs and serialization, but at the
>> lower level you still need to
>>
>> Conor: you end up designing as a set of setters and getters against
>> object model
>>
>> Scott: sort of, actually more of marshalling and unmarshalling so
>> that
>> when you need the DOM you reconstitute it
>>
>> Asa: important to have access to lower levels, but have a higher
>> level
>> api that can avoid complexity.
>>
>> Asa: need for DOM is mainly sigs, and mentioned in Wash meeting (what
>> was that date?)
>>
>> Scott: security was designed with streaming in mind, but SAML doesn't
>> lend itself for SAX based approach and Apache tried to build SAX
>> canonicalizer into xml security stuff and found it was hard.
>>
>> Asa: DOM uses more memory, but easier to get going
>>
>> Scott: Annoys the Mobile guys, but if you are using Java on a phone
>> don't worry about it (too big anyway)
>>
>> Asa: What is the audience? In terms of data size?
>>
>> Scott: large data is like multi-megabytes
>>
>> Conor: yeah, you negotiate the connection and protocol in SOAP but
>> the
>> actual data (like AOLradio) is a binary protocol
>>
>> Asa: like the idea of making the initial negotiation using SOAP, and
>> then moving to another stream
>>
>> Conor: but the first step should be trying to contact the established
>> services (eg profile service). Another thing is to invoke the Disco
>> service which is also a first step.
>>
>> Asa; envisioned a sequential approach, SSO, followed by DISCO,
>> followed by Service invoke
>>
>> Conor: has C++ that knows how to invoke services
>>
>> Asa: can you send a pointer to the piece of code
>>
>> Conor: offers to walk through the code with Asa
>>
>>
>> Asa: what should be the process going forward. Architecture doc is
>> Asa's responsibility, but he wants to get best input from the callers
>> and the list
>>
>> Brett: do you want to build the arch dynamically on wiki?
>>
>> Asa: wiki isn't totally wonderful, but it's the best tool available
>>
>> Asa: the other option is to write a document and distribute
>>
>> Scott: never written an arch doc, only code!
>>
>> Asa: can get very detailed in a arch doc, but doesn't envision
>> something that detailed. Break into components, so that can be
>> changed incrementally. Compares to radio station where planning on
>> the wiki diminishes enthusiasm
>>
>> Scott: well you are lucky if you get anyone to write documentation
>> you
>> are lucky. But the wiki reduces the need to continue to reinvent
>> documentation.
>>
>> Asa:
>>
>> Scott: but what you really need is interfaces ,not architecture.
>> Developers can work from that and avoid stepping on each other.
>>
>> Asa: should we do API first
>>
>> Scott: no, but you need to get there unless there are only 1 or 2
>> people working
>>
>> Asa: the pitch will also get more people involved. Need to have more
>> compelling scenario than the beer-and-pizza scenario
>>
>> Diego: several use cases are interesting (email sent to Asa will be
>> forwarded)
>>
>> Asa: since we are starting from the wiki, perhaps and outline
>> (objectives, ....). There are maybe pieces that some people take for
>> complete granted, and we need to capture those.
>>
>> Brett: need to enumerate the questions we need to answer before we
>> get
>> going (DOM vs. SAX)
>>
>> Conor: whether we need to run in a Jakarta or AXIS or ?
>>
>> Scott: SOAP stack (or even having one).
>>
>> Asa: WSDL issue didn't have a solution in Washington?
>>
>> Scott: that's why the soap stack decision is important
>>
>> Brett: are we able to answer some of these qs now?
>>
>> Eric: DOM seemed to be consensus
>>
>> Scott: but perhaps the Wash discussion noted that you don't get too
>> many signed responses, so there may not be an initial need to
>> validate
>> sigs. The transport usually securs the response.
>>
>> Conor: there is a slight hook in Disco that might use sigs, but not
>> typical
>>
>> Scott: there have been use cases discussed where the security of the
>> Server->client might use SAML (and signing) but it hasn't been
>>
>> Scott: Apache needs a DOM
>>
>> Asa: The timeline of the project, and the simplicity, plus signing,
>> seems to indicate DOM.
>>
>> Brett: is there any discomfort with that
>>
>> Conor: Key is that the programmers are working with objects at a
>> level
>> above DOM
>>
>> Scott: DOM is not a fun API to work with at the app layer.
>>
>> Scott: needs to be addressed on list:
>> JDK version we're targeting:
>> decisions on java libraries: endorse xerxes from apache. and
>> bouncy castle.
>> java development environment:
>>
>> Ajay / Diego:
>> eclipse and ant
>> crypto - bouncy castle
>>
>> Brett:
>> take a look at the Identity Landscape page on the wiki, started by
>> Gerald
>> Beuchelt
>> http://www.openliberty.org/wiki/index.php/Identity_Landscape
>>
>> !! Weekly design discussion, status updates.
>> Thursday as a design meeting 8am, PST
>> 2/2/07 4:46 PM
>> Every Thursday at 8am PST we will be having a dev meeting until
>> things are
>> under way
>>
>> --
>> ____________________________________________________
>> Eric Tiffany | eric at projectliberty.org
>> Interop Tech Lead | +1 413-458-3743
>> Liberty Alliance | +1 413-627-1778 mobile
>>
>>
>>
>> _______________________________________________
>> wsf-dev mailing list
>> wsf-dev at openliberty.org
>> http://lists.openliberty.org/mailman/listinfo/wsf-dev
>
>
>
> ------------------------------
>
> _______________________________________________
> wsf-dev mailing list
> wsf-dev at openliberty.org
> http://lists.openliberty.org/mailman/listinfo/wsf-dev
>
>
> End of wsf-dev Digest, Vol 2, Issue 3
> *************************************
>
> _______________________________________________
> wsf-dev mailing list
> wsf-dev at openliberty.org
> http://lists.openliberty.org/mailman/listinfo/wsf-dev
More information about the wsf-dev
mailing list