Hi Fred! I wonder if this is necessary at all? Maybe it is a better solution to implement the caching completly transparent to the current implementation, by just adding the __set_state() method to ezcMailPart and simply serialize the objects to be cached. This way, the complete email is cached and can be re-used.
The mail parts don't need to know if they are cachable. If you just want to change the plain-text part, the overhead of restoring this is not as large as it would make sense to disable its caching. What still needs to be done is, that message ID and stuff must be reset, which should be up to the user on de-serialization. This way, caching can be used more flexible, like building a mail step-wise over muliple requests, if someone wants something like this. We can then offer a backend in the Cache component, which can handle objects that implement __set_state(), which we should do anyway, I think. I'm I misleaded? Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
