>> >> Shell scripting is an interesting idea and certainly something that >> could be added. However, to me, it sounds more like a power user >> convenience. >> >> Here's another approach. Why not simply imagine a directory structure >> that lays out the various parts of the problem, e..g >> >> domain1 >> contributions >> contribution1.zip >> (contributions don't need to be here physically if they are >> accessible from elsewhere via a URL) >> nodes >> node1config.xml >> >> Then run a "shell" (I put it in speach marks as we seem to have >> several shells at the moment and I'm not sure what is actually being >> discussed here) over it and have it start the available node config >> (or indeed create a new node config and start that). >> > > The "tuscany shell script files as files containing shell commands on > each line" and the node1config.xml approaches seem pretty similar. > > You can actually use files of shell commands right now by just > redirecting sysin from a file (eg java -jar > tuscany-base-nodep-2.0-20100929.095517-1.jar < fileOfCmds) but ther > doesn't seem to be any way to switch back to read from the console > afterwards so it might be better to add an extra startup parameter > for the command file, and that way you can run the script commands and > then use the shell command line to continue using commands to display > the state and make updates. > > I like the idea of supporting node xml as well though so think we > should add shell commands like load and save that read and write the > xml files. And then you can have something like helloworld.xml and in > the shell do load helloworld.xml to run the helloworld sample. And for > each of the samples provide the xml file to configure everything for > the sample. > > ...ant >
Adding/removing contributions/nodeconfig.xml to the appropriate directories could have the same effect a. la. Tomcat. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
