In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.
Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.
Permanent link for public information only:
Permanent link for all public and protected information:
(Genoa University/INFN), Dave Dykstra
(Fermi National Accelerator Lab. (US))
Technical Evolution Groups – Mandate
To reassess the implementation of the grid infrastructures that we use in the light of the experience with LHC data, and technology evolution, but never forgetting the important successes and lessons, and ensuring that any evolution does not disrupt our successful operation.
The work should:
Document a strategy for evolution of the technical implementation of the WLCG distributed computing infrastructure.
This strategy should provide a clear statement of needs for WLCG, which can also be used to provide input to any external middleware and infrastructure projects.
The work should, in each technical area, take into account the current understanding of:
Experiment and site needs in the light of experience with real data, operational needs (effort, functionality, security, etc.), and constraints;
Lessons learned over several years in terms of deployability of software;
Evolution of technology over the last several years;
Partnership and capabilities of the various middleware providers.
It should also consider issues of:
Long term support and sustainability of the solutions;
Achieving commonalities between experiments where possible;
Achieving commonalities across all WLCG supporting infrastructures (EGI-related, OSG, NDGF, etc).
Assessment of the current situation with middleware, operations, and support structure
Strategy document setting out a plan and needs for the next 2-5 years
Databases Working Group Topics
The bullets represent the topics that should be included in the discussions, but are not exclusive.
NOSQL vs Oracle, MySQL, etc
Frontier, squids, vs 3D/Streams, GoldenGate, DataGuard etc
What is framework for deploying new applications that need a DB? (e.g. if dev has used a random db, how is that made into a service?)
We do not want to repeat information from the June 2011 Database Futures Workshop (http://indico.cern.ch/conferenceTimeTable.py?confId=130874), especially things describing the current situation, although a quick refresher on plans shared then can be helpful. We want to focus on what should be changing over the next 2-5 years, both things currently planned and especially things not yet planned but which are lacking or could be improved or could be better shared between experiments. Bring proposals, or describe ideas during discussion time, or at least talk about what the needs will be if not the solutions. Set your sights on after the long 2013 shutdown and later.