Hi, * Martin Aliger wrote on 09.07.2004 (13:43): > to pass information from one task to other. Since speed is not main interest > in automated builds (sorry Matt - I still appreciate your optimization > work!) XML should be straightforward solution. But I never think we will > serialize XML on every task. XML hierarchy is pretty efficiently stored in > memory like object tree and that should be enough (what is exactly what you > propose, isn't it?)
Task communication is no more than sharing information in the mean of a variable all tasks can read (or a memory location with XML or what-ever in it). When I think a bit more of sharing information throughout tasks I come to these points: In a programming language, data can be: * private * public * protected * static and with a bit more work * persistent IMO there is no situation where I can think of a need for 'declaring' something static in NAnt if there would be task communication[1]. Correct me if you can imagine. IMHO private data is always task-instance specific and doesn't need to be tracked by a NAnt wide communication system. Public data can be shared with other tasks without restrictions. Protected data can only be accessed by tasks of the same type (like my stopwatch task). I'll focus on persistent data later. How about introducing a 'DataStore' that is working comparable to the properties: this.Project.DataStore.Save(object); this.Project.DataStore.Save(name, object); this.Project.DataStore.Save(name, object, type); First function would be the magic variable. If set in a task, this value remains. If not set, the output of the task could be written to this special variable. So a load operation always refers to the task running before. Second function would lay an object in the data store with a key so it can be accessed from all tasks. The last function adds a protected object to the store only readable from a task of the same type. The protected Load operations would work analog to this. A few words to persistence. Imagine two more overloads, that indicate using a boolean variable if an object should be persistent. When a data store property on the project is set, a datastore with all variables marked persistent will be saved to the given file (and loaded at the beginning of the next run). Personally I would restrict the use of persistent data to objects that are serializable for the sake of easy save and restore. In a first version I would try a datastore based on hashtables. But that's a step further. And after a second thought there are some things certainly coming up if task communication is possible: * How can I list all key / value combinations in the datastore? * Can there be persitence over the bounds of a buildfile? * Can I persist data only accessible to one specific task-instance? The persistence feature is certainly very interesting, but would definitly lead to much more possible complexity in both the build files and the tasks. This should be taken into account. Nevertheless I would call me a supporter for the idea of communication as it would have been great if I could have used this in my own version task and probably the stopwatch task. And to close the run with XML: If a task lays XML to the store or not would be up to the tasks author. In some cases this is a nice, straightforward way to organize information, in others not. Who cares if you can use the store for all kind of objects? -sa [1] This is IMHO true as long as NAnt doesn't use a high level language to write buildfiles ;) -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
