GridPP17 Discussion Session 8: What is Middleware Support?
==========================================================

Chair: Steve Lloyd (SL)
Panel: Mona Aggarwal (MA), Tom Doherty (TH), Barney Garrett (BG), Jens
Jensen (JJ), Andrew McNab (AM), Robin Middleton (RM), Paul Millar (PM),
Robin Tasker (RT)
Notes: Catalin Condurache

SL presented a slide with the summary of a similar discussion at
GridPP14 Birmingham.

RM
What should be the model for long term? In house support for LHC
lifespan only, continue the same model or outsourcing it (the support)?
User documentation increased chaotically
Functionality not rich enough
Middleware not available on all platforms

PM
Three ways - make it more robust, more features, documenting it
Documentation is part of the general communication
Good communication between developers is needed

JJ
T2s have to deliver good services, so GridPP could be a success
Knowledge databases should be maintained beyond GridPP2, GridPP3
regarding CPU, storage
Need a link with people that can do performance engineering (i.e.
networking but not only)

MA
Logging messages not very clear, even if long

BG
Awful lots of solutions (wheel re-invented too many times)
Need to standardise things (i.e. only one storage solution, not many)

AM
The support for middleware is transformed in middleware development
because of features needed but non-existent; they are created locally

Audience
- But what should be middleware? It is fragmented because of many
developers, but need to try to keep it together.
- What other countries are doing in this respect?
- Proposal to create groups with GridPP related to specific things
(networking, storage, ...) - to be discussed at DTeam meeting

Conclusion: the same problem - communication