Wed morning o define agenda o Release policy and s/w process - release policy (backward compatibility et al) - organization of the repository and contrib area - utils/tools code using AIDA IFs ? Test and examples will be part of the repository, maintained by the AIDA core team. Contributions based on the Interfaces are very welcome and will go into a separate repository (e.g., FreeHep, Sourceforge) and will be maintained by the contributor. Policy statements are subject to periodic review at workshops. New repository structure: ((( $CVSROOT/CVSROOT/modules: cpp interfaces/cpp (or vice versa) ))) AIDA/ tests/ java/ cpp/ python/ examples/ java/ cpp/ python/ interfaces/ java/ cpp/ python/ xml/ doc/ <<-- user documentation web/ ?? swprocess/ <<-- architecture document, design diagrams To be finalized. Release frequency, scheduling. Release naming/numbering: minor releases: users need to re-compile only, major releases: users may need to change source "X.Y" (.d for changes not related to source, e.g., documentation ... only as tag in repository, for the users the changes are on the web). Changes in semantics like: ITree::close() does/doesn't call ITree::commit() ... these are reflected in "X" (.i.e., major release). Release frequency: two releases per year for the users. At the present the releases are major releases. For implementors, internal tags are provided which will not comply to the release numbering policy (i.e. "minor" releases may/will require code change). The release to users will be done some time after the last internal tag in order to allow implementations to be ready with the release. Time line: internal releases 2.3 june 15, 2.4 (?) aug 15, 2.5(??)-->3.0 sept. 30 Rename 2.4/2.5 as 3.0 for users and release september 30. Future releases are foreseen to be in spring and fall. Feedback from users is collected through an archived mailing list (project-aida@cern.ch). Either users send requests directly or from discussions, e.g., at user workshops. The developers will then come with a proposal on how to integrate the proposals. o Object Management - Should we be "religious" about everything being an I* (==> use Factories) ? Yes. Possible items for future discussions are a common Facade pattern (on top of the Interfaces) to hide some of the underlying complexity from the user. - Should everything created by Factories appear in the Tree ? Yes: Histos, Clouds, Tuples, Function No : Plotter, Fitter, Evaluator, Filter - Should the Factories be coupled to the Tree ? They don't have to be coupled to the Tree. An individual instance of a Factory does not have to have a Tree associated with it. Factories which are NOT associated with a Tree transfer ownership to the user, Factories which ARE associated with a Tree KEEP ownership. 0a managed, in AIDA 2.2) ITree * tree=tf.create() IHistogramFactory *hf=af.createHistogramFactory( *tree ) IHistogram * h1=hf->create("name", "label", 10, 0., 100.) IHistogram * h2=hf->create("nameAndLabel", 10, 0., 100.) tree is not allowed to be 0 0aa managed but not by tree: IHistogram * h1 = histoSvc.createH1D("name", "label", 10, 0., 100.) histoSvc.removeAndDestroyHistogram( h1 ) h1 and h2 are managed by tree (must not be deleted explicitely by user, only tree.rm()) 0b unmanaged, in AIDA 2.3) IHistogramFactory *hf=af.createHistogramFactory(0) IHistogram * h1=hf->create("name", "label", 10, 0., 100.) IHistogram * h2=hf->create("nameAndLabel", 10, 0., 100.) h1 and h2 are managed by user (must be deleted explicitely by user) Beware 0a: If tree == 0 "by accident" (e.g., tf.create() failing) the semantics of ownership changes for the created histograms !!! 1 managed) IHistogram * h1=hf->create("name", "label", 10, 0., 100., tree) IManagedHistogramFactory *hf=af.createMgtHistogramFactory(0) IMgtHistogram * h1=hf->create("name", tree, "label", 10, 0., 100.) 2 unmanaged) IHistogram * h1=hf->create("label", 10, 0., 100.) All of the above was discussed (> 4 hrs). Solution 0a (AIDA 2.2) was taken to be the user-level solution. *** WORK *** Add clone() methods to the IHistogramFactory: IHistogram1D * createCopy(const string & path, const IHistogram1D &) = 0; IHistogram2D * createCopy(const string & path, const IHistogram2D &) = 0; IHistogram3D * createCopy(const string & path, const IHistogram3D &) = 0; *** end WORK *** What's the difference to ITree::cp() ? Maybe should not be allowed? Requires that tree knowns about factory Tree.rm() is not ideal way of deleting histograms tree.rm(tree.findPath(h1)) *** WORK *** Should we have tree.rm(IManagedObject) No // Removes from tree, and deletes object histogramFactory.destroy(IBaseHistogram) -- Least Bad choice. *** end WORK *** h1.rm()--noway ?? delete h1; --noway // Would require histogram to know about tree should factories have tree() method? No *** WORK *** Should Tree allow two objects with same path? No. If not what should happen -- replace?, error? warning? Do nothing? User should specify strategy tree.setOverwrite(boolean) ("overwrite=true") At all places where we have name we should say path? -- Yes IManagedObject.name() only returns name (not full path -- only tree knows path) tree.setAutomaticFolderCreation(boolean) (or option) : allows the tree to create missing directories if a path is given to an object "outside" the tree. *** end WORK *** - coupling of Factory, Tree and Store ? Should be decoupled at developer level. Wed afternoon o Discussion of remaining user wishes/user requirements o IXYData / Vector of Points - Explicit error propagation strategy o General discussion on developer interfaces - goals for having devIFs - high level overview on what type of devIFs - "packaging"/definition of components o) Allow separation of functionality (e.g store, managment, creation) o) Allow sharing of low level functionality o) Allow interoperabilty of components o) Hints to implementers of possible strategy