- Class mobject::session::AbstractMO
- seems that we don't need this intermediate class...
- Member mobject::session::Allocation::intersect (LocatingSolution &) const
- probably a placeholder and to be pushed down....
- Class asset::Category
- could be far more elaborate. could be a singleton like centralized tree, while just holding references to Catetory nodes in the individual Asset. At the moment, we use just the most simplistic implementation and handle Category objects using value semantics.
- Member asset::Category::operator string () const
- to be localized.
- Class mobject::session::Clip
- define how to denote Time positions /lengths. This is tricky, because it depends on the actual media type, and we want to encapsulate all these details as much as possible.
- Member mobject::session::Clip::mediaDef_
- using a mere ref here is against the scheme and only done as temporal solution, until we work out how to handle multichannel clips. It should be a smart pointer of some kind and the unlink() function of the asset should take it into account when breaking circular references.
- Class mobject::session::DefsRegistry
- as of 3/2008 the real query implementation is missing, and the exact behaviour has to be defined.
- Class mobject::session::FixedLocation
- use a subclass to represent the LocatingSolution? would solve the construction of a ExplicitPlacement much more natural. (ichthyo: siehe trac #100)
- Member mobject::session::LocatingPin::resolve () const
- this could/should be replaced by a full-blown constraint solver at some point in the future
- Member mobject::session::LocatingPin::resolve () const
- we are packing and unpacking the information (time,track) several times. Ichthyo considers a more elegant solution.
- Class mobject::session::LocatingPin::LocatingSolution
- we can't sensibly reason about tracks, because at the moment (10/07) we lack a track implementation...
- Class mobject::session::LocatingPin::LocatingSolution
- shouldn't we use a range-restriction LocatingPin (subclass) to represent the to-be-found solution? (ichthyo: siehe Trac #100)
- Class asset::Meta
- just a stub, have to figure out what a asset::Proc is
- Member asset::MetaFactory::operator() (Asset::Ident &key)
- actually define
- Member mobject::MObject::getLength ()=0
- how to deal with the time/length field??
- Class lumiera::singleton::Multithreaded< S >
- actually implement this policy using the Lumiera databackend.
- Class asset::Proc
- just a stub, have to figure out what a asset::Proc is
- Member asset::ProcFactory::operator() (Asset::Ident &key)
- actually define
- Member asset::ProcPatt::ProcPatt (const Asset::Ident &idi)
- preliminary implementation, storing the capabilities in the asset name field. We can do better, when it's clear what capabilities we need
- Member mobject::session::SessManager::save ()=0
- how to serialize, prameters, return value?
- Member mobject::session::SessManagerImpl::reset ()
- for this to work, we need to change the implementation of AssetManager so support this kind of transactional switch!
- Class asset::Struct
- just a stub, have to figure out what a asset::Proc is
- Member asset::StructFactory::operator() (const Query< STRU > &query)
- work out the struct asset naming scheme!
- Class asset::StructFactoryImpl
- better use a general struct traits class, esp.for creating the Ident
- Class mobject::session::test::TestClip
- make this usable as Mock object to record invoked operations.
- Class lumiera::Thread
- actually implement this policy using the Lumiera databackend.
- Class lumiera::Time
- currently (9/07) this is a dummy implementation to find out what interface the Proc layer needs. Cehteh has already written elaborate timehandling functions in the backend and the goal is for class Time to be just a thin wrapper!
- Member asset::Track::Track (const Asset::Ident &idi)
- work out the details of track assets
- Class lumiera::query::TypeHandler< TY >
- it can't be done exactly this way, but I leave it in as a reminder for later, to show the intention
- Class asset::Unknown
- maybe do special handling of the media length, allowing it to support existing clips even if the media length is not known?
Generated on Sat Aug 16 18:10:40 2008 for Lumiera by
1.5.5