[Clam-devel] PATCH: new File class heirarchy

[Xavier Amatriain]

On Wed, 2007-04-11 at 13:40 +0200, Pau Arumi wrote:
> xavi, are you talking hypothetically? because this is not the 
> design in clam. and i like the current storage design it let you 
> do things like
> 
> Network network;
> XMLStorage::Restore(network, "my.clamnetwork");

I like that also but that is not the way you do things with all the file
types (the ones I was talking about like Audio, SDIF, MIDI...). All I am
saying is that we should have a unified approach. If we agree that is
the right interface for passivating/activating objects we should be able
to do:

SDIFStorage::Restore(segment, "mysegment.xml");

or

AudioStorage::Restore(audio, "test.wav");

Is there any reason to keep things different in these cases?

> and moreover Network is not coupled with XML (look at the
> interface [1]) but only with generic Storage class --though this
> abstraction was not that useful as david pointed out.

The first line in Network::StoreOn instantiates an XMLAdapter... you
call that not being coupled?


> i think that mixing storage and qtconfigurators matters is wrong.
> the File (oh, why don't call it something like
> ConfigurableFileName, please?) refactoring was (or should, imo)
> restricted to the second area (qtconfigurators).
> agree?

Agree, actually even I had to go back through the thread to understand
where things got tangled. Ideally at some point they might meet but
right now it's better to keep refactorings and discussions focused.