Reference Implementation Meeting 2010-07-13
Date: July 13, 2010
Time: 12pm-1pm
Attendees: Teresa Black, Ravi Madduri, Vince Lewis, Umesh Madan, Arien Malec, Uvinie Hettiaratchy, Chaminda Gunaratne, Chris Lomonico, Srinivas Koka, Brian Behlendorf, Doug Arnold, Chris Moyer, Claudio Sanchez, Vassil Peytchev
Actions for this Week
# |
Date |
Action |
Status |
Owner |
Due Date |
4 |
07/13/10 |
Draft commit process document |
Open |
Brian |
7/20/10 |
5 |
07/13/10 |
Second pass review of component list |
Open |
Arien |
07/20/10 |
6 |
07/13/10 |
Develop set of procedures around contribution of code |
Open |
Brian/Arien |
07/20/10 |
7 |
07/13/10 |
Review draft open source policy |
Open |
WG |
07/20/10 |
8 |
07/13/10 |
Start work in Agent team and XDS B metadata team |
Open |
WG |
07/20/10 |
Actions from last Week
# |
Date |
Action |
Status |
Owner |
Due Date |
2 |
07/06/10 |
Draft initial open source policy for reference implementation work |
Open |
Brian |
07/06/10 |
3 |
07/06/10 |
Create a matrix/list of components to prioritize and determine scope for reference implementation work |
Open |
Arien |
07/13/10 |
Agenda
- Review draft list of components and prioritize and determine scope
Notes
Brian Behlendorf
- I committed BSD license without much time to review so not expecting lots of comments during this meeting, but would like to see a review over the next week.
- Commentary given through wiki page by next week.
- Put it up about 45 minutes ago.
- Will link it from the Reference Implementation wiki.
- Read through to make sure there’s a common understanding.
- Comment on timeframe of next wiki for reiterations.
- More than having a consensus, would like to do a round the room for agreement.
- In terms of summary, not unusual for any other open source project.
Arien Malec
- 2 things – need to keep licensed information visible and each of the relevant source files. Number 2, proposals for how to mix licenses.
- Quick summary for proposal for how to mix licenses?
Umesh Madan
- For those of us who have not familiar with open source, it’d be helpful to have a checklist.
Brian Behlendorf
- I’ll take the checklist into account.
- The big thing is that we do want to keep authorship clear.
- We want to make sure that people get credit for their contributions and that organizations are clear that when they’re employees are contributing they don’t do that outside of their IP rights.
- I think we’re trying to build a collection of work for one software package or series of packages that could be treated in a lightweight way. This license could apply for this whole body of work.
- When building web based application, you’re going to build on pre-existing work with lots of licenses.
- Trying to anticipate one kind of bifurcation – publish under NHIN Direct code and publishing under a distribution.
- The question of third party pre-existing code is a question of including something for convenience to bootstrap at deployment.
- If include it inside of core NHIN Direct reference implementation code base, it should fit within grant of BSD license – TPL software would not fly.
- The kinds of things you’d want to include – always need SHA algorithm for security , etc. The third party code that sits outside of that, under distribution, could be replaced. Not a critical dependency.
- That’s the major distinction in section 3 – inclusion of third party code.
- Section 4 – code depositories should have a commit policy that gives us same amount of flexibility and community involvement as wiki has today.
Umesh Madan
- Anyone can edit the code? Or code review process?
Brian Behlendorf
- There’s a whole world of additional workflow we can implement on top of this.
- Hoping to set baseline of governance – the policy that has worked on wiki is likely to work for us in the code.
- Open to discussion – want to avoid insider-outsider dichotomy in project.
Umesh Madan
- I would worry if people were editing this randomly. This is a classic code tree. Some gatekeeper may be necessary.
Brian Behlendorf
- Couple of tools at our disposal – notifications of change (like in Wiki)
Arien Malec
- Freeze discussion because outside issue of licensing. Let’s separate this process from core licensing process.
Brian Behlendorf
- Will clarify language.
- Valuable to have standard commit process.
- Brian to draft commit process document.
Brian Behlendorf
- Section 2 – one thing I’ll note is that the organization that we’re using for this is a fictional entity – NHIN Direct Project. As long as you recognize not legal entity, and represents informal collection of people, says enough to prepare us for this project. Used as legal shorthand for collective interest of contributors.
- Everyone should get due credit while being agile.
Arien Malec
- Credit is important because copyright can’t be given away. It’s really important to keep track of authorship and people who have participated.
- They all have copyright claim to resulting codebase. Keep track that they contribute codebase with clear set of licensing considerations.
Round the Room
Teresa Black |
|
Ravi Madduri |
|
Vince Lewis |
|
Umesh Madan |
|
Chris Lomonico |
|
Sri Koka |
|
Doug Arnold |
|
Chris Moyer |
|
Claudio Sanchez |
|
Vassil Peytchev |
|
Arien Malec
- Make sure you’re contributing code on individual basis.
- You may have particular limitations on your ability to do that based on contracts you have signed for employment, which vary by company.
- By contributing to codebase, you are warranting you can do so and can license your addition.
- I’d like to switch over to set of reference implementation components.
- If you go to reference implementation page, link available for the components.
- I looked at all the work we discussed and iterated out all of the key components.
- Agent
- Implementation of S/MIME signing and encryption, Alpha implementations in C# and Java
- End-to-End SMTP HISP
- Combination of commodity SMTP server (Apache James, Postfix, etc.) and Agent
- XDS Metadata
- Reader/writer for XDS metadata
- Several implementations may be extractable from XDS open source implementations
- XDM
- Reader/writer for zip-compressed XDM packages (XDS metadata + HTML manifest + directory structures and zipping
- XDD
- Implementation of XDR that separates content from address headers
- Client Library
- Encapsulates sending and receiving content, including S/MIME and XDM packaging/unpackaging and SMTP + IMAP4 client operations
- Health Content Metadata Extractor
- Sniffs and extracts standardized metadata from a variety of health content types (HL7 v2, CDA/CCD, CCR, etc)
- SOAP XDS packaging to XDM packaging
- Extracts the MTOM-encoded payload of an XD* SOAP transaction and transforms to equivalent XDM packaging and vice versa
- SMTP/XDD Gateway
- Receives content via SMTP, sends via XDD and vice versa, uses metadata extraction and client libraries
- These are the 9 or 10 components I saw as being valuable and a break out of those components would make sense.
Round on if these components are correct and necessary, if anything is missing, and if the division of the components makes sense.
Teresa Black |
|
Ravi Madduri |
|
Vince Lewis |
|
Umesh Madan |
|
Chris Lomonico |
|
Sri Koka |
|
Doug Arnold |
|
Chris Moyer |
|
Claudio Sanchez |
|
Vassil Peytchev |
|
Chaminda Gunaratne |
|
Brian Behlendorf
- I feel like we should specifically call out need to focus on end user interfaces and manager interfaces.
- Want to make sure we’re building something that’s not just collection of components but can be used in implementation geographies.
- Need to start thinking about end user web interfaces for things like managing a key.
Arien Malec
- Another component is the proxy configuration for agent. It’s possible that we can put that in nice to haves.
Brian Behlendorf
- We need to know what we need to facilitate the pilots.
Arien Malec
- I think that’s a great point. Want to hold this discussion in another round. I want to make this easy for developers and let them innovate for patients and providers. I may be wrong on that.
Umesh Madan
- One thing we should figure out next time is that there are 2 implementations using two different stacks and we should make sure they are interoperable. It might be handy to have a running system where we have the .NET and Java bits deployed and test if they can communicate with each other. We’ll figure out how to do that.
Arien Malec
- A nice smoke test that works across both would be ideal. We have 10 more minutes, I’m going to take another pass at components. I’d like to define two teams and get another project up and running around existing implementation of .NET and Java agent.
- I propose for next meeting that we move these two implementations into a source code repository and that will serve as our tree. Form Committer forms for those two implementations. Let’s do a call for volunteers for those teams.
- I’d also like to see if we could get started on XDS B metadata reader/writer as a second component. Volunteers for that as well.
Round on: '
1) 'Useful set of things to start working on?
2) 'Would you like to be part of Agent core team?
3) 'Interest in part of XDS B metadata core team? Perhaps things we can steal.
Teresa Black |
|
Ravi Madduri |
|
Vince Lewis |
|
Umesh Madan |
|
Chris Lomonico |
|
Sri Koka |
|
Doug Arnold |
|
Chris Moyer |
|
Claudio Sanchez |
|
Vassil Peytchev |
|
Chaminda Gunaratne |
|
Brian Behlendorf
- Good idea.
Arien Malec
- I propose we use Mercurial for source code management tool. Chris do you agree or disagree?
Chris Lomonico
- Mercurial is good. Comfortable with that.
Arien Malec
- We’ll publish a quick getting started guide for Mercurial. Lets you do checklists.