Jenkins build is back to stable : oodt-trunk ยป CAS Protocol IMAPS Implementation #140
See https://builds.apache.org/job/oodt-trunk/org.apache.oodt$cas-protocol-imaps/140/
Jenkins build is back to stable : oodt-trunk #140
See https://builds.apache.org/job/oodt-trunk/140/changes
CAS-CLI option standardiztion...
hey guys,okay so the workflow and resource manager have been upgraded to using cas-cli... they maintained the same look as they had before... now the question i have is: the command-line look they have now, is that the look we want going forward or do we want to give the command-line a new look... if we decide to change the command-line, backward compatibility can be easily maintained by keeping the current cas-cli spring xml files around and all any user has to do is point at those spring files and workflow and resource manager command-line will work and look like it always has... i don't really have an opinion one way of the other, but my next component which is going to get cas-cli is the crawler, and it's command-line doesn't look like the workflow or resource manager (probably my fault)... so i would like to make it either look like the workflow and resource manager (i.e. --operation --action) or make the workflow and resource manager look more like the crawler... or given them all a "new" look... either way i would like to make all the components' command-line work in a way such that if you learn one, you learn them all... let me know what you guys think.-brian
Re: CAS-CLI option standardiztion...
Hey duder, On Nov 18, 2011, at 2:28 PM, holenoter wrote: hey guys, okay so the workflow and resource manager have been upgraded to using cas-cli... they maintained the same look as they had before... They look amazing. A true testament to the great generic cli framework you've made. now the question i have is: the command-line look they have now, is that the look we want going forward or do we want to give the command-line a new look... if we decide to change the command-line, backward compatibility can be easily maintained by keeping the current cas-cli spring xml files around and all any user has to do is point at those spring files and workflow and resource manager command-line will work and look like it always has... i don't really have an opinion one way of the other, Yeah I'm kind of the same way. I'm used to the FM WM and RM working that way (with the --operation action step), so I'm not necessarily looking for them to change much. We also haven't had a lot of complaints. I've heard the occasional complaints about --operation, but I haven't seen a lot of folks willing to put in the effort that you have to get them all integrated and unified together, and/or changed. Because of that, I'm tentative to actually suggest they should be changed. Furthermore, I guess in a way we could consider the FM, WM and RM to be different beasts than e.g., crawler and/or pushpull and cas-pge since they are the core *services* and the crawler/pushpull and cas-pge are really client-side frameworks. See more below. but my next component which is going to get cas-cli is the crawler, and it's command-line doesn't look like the workflow or resource manager (probably my fault) Nah, you were just ahead of your time per usual :-) ... so i would like to make it either look like the workflow and resource manager (i.e. --operation --action) or make the workflow and resource manager look more like the crawler... or given them all a new look... either way i would like to make all the components' command-line work in a way such that if you learn one, you learn them all... let me know what you guys think. I'm +1 for your statement about knowing one of them, and then knowing them all. However, I think you've done that from the perspective of having your statement now be true with FM, WM and RM. And I think you're going to do that for the other client frameworks and they will look the same. Having said that, the differences are pretty small (whether or not an --operation flag has to be passed to fire off the action with name action, compared to baking in the action name into the --flag. That's not too different. I think being on cas-cli will help bring them all together in the long run anyways, but I don't see a huge value added from changing the CLI contracts as they have existed for a while. On the other hand, I see a HUGE advantage for standardizing the software framework with a flexible CLI framework like you've created to help that. My 2 cents. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: CAS-CLI option standardiztion...
oh that's right... filemgr... how could i forget about the filemgr???.. i'll do that one next... i'll integrate all the random tools into the client's supported actions as well... such as the delete and query tools.. then in the mean time we can talk about how we want the crawler command-line to look... i'll create an issue for both the filemgr and crawler with cas-cli so we have a place to keep this conversation going... onto the filemgr conversion then...-brianOn Nov 18, 2011, at 03:01 PM, "Mattmann, Chris A (388J)" chris.a.mattm...@jpl.nasa.gov wrote:Hey duder, On Nov 18, 2011, at 2:28 PM, holenoter wrote: hey guys, okay so the workflow and resource manager have been upgraded to using cas-cli... they maintained the same look as they had before... They look amazing. A true testament to the great generic cli framework you've made. now the question i have is: the command-line look they have now, is that the look we want going forward or do we want to give the command-line a new look... if we decide to change the command-line, backward compatibility can be easily maintained by keeping the current cas-cli spring xml files around and all any user has to do is point at those spring files and workflow and resource manager command-line will work and look like it always has... i don't really have an opinion one way of the other, Yeah I'm kind of the same way. I'm used to the FM WM and RM working that way (with the --operation action step), so I'm not necessarily looking for them to change much. We also haven't had a lot of complaints. I've heard the occasional complaints about --operation, but I haven't seen a lot of folks willing to put in the effort that you have to get them all integrated and unified together, and/or changed. Because of that, I'm tentative to actually suggest they should be changed. Furthermore, I guess in a way we could consider the FM, WM and RM to be different beasts than e.g., crawler and/or pushpull and cas-pge since they are the core *services* and the crawler/pushpull and cas-pge are really client-side frameworks. See more below. but my next component which is going to get cas-cli is the crawler, and it's command-line doesn't look like the workflow or resource manager (probably my fault) Nah, you were just ahead of your time per usual :-) ... so i would like to make it either look like the workflow and resource manager (i.e. --operation --action) or make the workflow and resource manager look more like the crawler... or given them all a "new" look... either way i would like to make all the components' command-line work in a way such that if you learn one, you learn them all... let me know what you guys think. I'm +1 for your statement about knowing one of them, and then knowing them all. However, I think you've done that from the perspective of having your statement now be true with FM, WM and RM. And I think you're going to do that for the other client frameworks and they will look the same. Having said that, the differences are pretty small (whether or not an --operation flag has to be passed to fire off the action with name action, compared to baking in the action name into the --flag. That's not too different. I think being on cas-cli will help bring them all together in the long run anyways, but I don't see a huge value added from changing the CLI contracts as they have existed for a while. On the other hand, I see a HUGE advantage for standardizing the software framework with a flexible CLI framework like you've created to help that. My 2 cents. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: CAS-CLI option standardiztion...
You rox! Cheers, Chris On Nov 18, 2011, at 5:23 PM, holenoter wrote: oh that's right... filemgr... how could i forget about the filemgr???.. i'll do that one next... i'll integrate all the random tools into the client's supported actions as well... such as the delete and query tools.. then in the mean time we can talk about how we want the crawler command-line to look... i'll create an issue for both the filemgr and crawler with cas-cli so we have a place to keep this conversation going... onto the filemgr conversion then... -brian On Nov 18, 2011, at 03:01 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey duder, On Nov 18, 2011, at 2:28 PM, holenoter wrote: hey guys, okay so the workflow and resource manager have been upgraded to using cas-cli... they maintained the same look as they had before... They look amazing. A true testament to the great generic cli framework you've made. now the question i have is: the command-line look they have now, is that the look we want going forward or do we want to give the command-line a new look... if we decide to change the command-line, backward compatibility can be easily maintained by keeping the current cas-cli spring xml files around and all any user has to do is point at those spring files and workflow and resource manager command-line will work and look like it always has... i don't really have an opinion one way of the other, Yeah I'm kind of the same way. I'm used to the FM WM and RM working that way (with the --operation action step), so I'm not necessarily looking for them to change much. We also haven't had a lot of complaints. I've heard the occasional complaints about --operation, but I haven't seen a lot of folks willing to put in the effort that you have to get them all integrated and unified together, and/or changed. Because of that, I'm tentative to actually suggest they should be changed. Furthermore, I guess in a way we could consider the FM, WM and RM to be different beasts than e.g., crawler and/or pushpull and cas-pge since they are the core *services* and the crawler/pushpull and cas-pge are really client-side frameworks. See more below. but my next component which is going to get cas-cli is the crawler, and it's command-line doesn't look like the workflow or resource manager (probably my fault) Nah, you were just ahead of your time per usual :-) ... so i would like to make it either look like the workflow and resource manager (i.e. --operation --action) or make the workflow and resource manager look more like the crawler... or given them all a new look... either way i would like to make all the components' command-line work in a way such that if you learn one, you learn them all... let me know what you guys think. I'm +1 for your statement about knowing one of them, and then knowing them all. However, I think you've done that from the perspective of having your statement now be true with FM, WM and RM. And I think you're going to do that for the other client frameworks and they will look the same. Having said that, the differences are pretty small (whether or not an --operation flag has to be passed to fire off the action with name action, compared to baking in the action name into the --flag. That's not too different. I think being on cas-cli will help bring them all together in the long run anyways, but I don't see a huge value added from changing the CLI contracts as they have existed for a while. On the other hand, I see a HUGE advantage for standardizing the software framework with a flexible CLI framework like you've created to help that. My 2 cents. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: CAS-CLI option standardiztion...
I say as long as --help can tell me what I need to know to get it working then we all win. No matter which you choose, please keep up the great docs. Great docs are always in fashion. :-D Cameron On Nov 18, 2011 6:00 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: You rox! Cheers, Chris On Nov 18, 2011, at 5:23 PM, holenoter wrote: oh that's right... filemgr... how could i forget about the filemgr???.. i'll do that one next... i'll integrate all the random tools into the client's supported actions as well... such as the delete and query tools.. then in the mean time we can talk about how we want the crawler command-line to look... i'll create an issue for both the filemgr and crawler with cas-cli so we have a place to keep this conversation going... onto the filemgr conversion then... -brian On Nov 18, 2011, at 03:01 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey duder, On Nov 18, 2011, at 2:28 PM, holenoter wrote: hey guys, okay so the workflow and resource manager have been upgraded to using cas-cli... they maintained the same look as they had before... They look amazing. A true testament to the great generic cli framework you've made. now the question i have is: the command-line look they have now, is that the look we want going forward or do we want to give the command-line a new look... if we decide to change the command-line, backward compatibility can be easily maintained by keeping the current cas-cli spring xml files around and all any user has to do is point at those spring files and workflow and resource manager command-line will work and look like it always has... i don't really have an opinion one way of the other, Yeah I'm kind of the same way. I'm used to the FM WM and RM working that way (with the --operation action step), so I'm not necessarily looking for them to change much. We also haven't had a lot of complaints. I've heard the occasional complaints about --operation, but I haven't seen a lot of folks willing to put in the effort that you have to get them all integrated and unified together, and/or changed. Because of that, I'm tentative to actually suggest they should be changed. Furthermore, I guess in a way we could consider the FM, WM and RM to be different beasts than e.g., crawler and/or pushpull and cas-pge since they are the core *services* and the crawler/pushpull and cas-pge are really client-side frameworks. See more below. but my next component which is going to get cas-cli is the crawler, and it's command-line doesn't look like the workflow or resource manager (probably my fault) Nah, you were just ahead of your time per usual :-) ... so i would like to make it either look like the workflow and resource manager (i.e. --operation --action) or make the workflow and resource manager look more like the crawler... or given them all a new look... either way i would like to make all the components' command-line work in a way such that if you learn one, you learn them all... let me know what you guys think. I'm +1 for your statement about knowing one of them, and then knowing them all. However, I think you've done that from the perspective of having your statement now be true with FM, WM and RM. And I think you're going to do that for the other client frameworks and they will look the same. Having said that, the differences are pretty small (whether or not an --operation flag has to be passed to fire off the action with name action, compared to baking in the action name into the --flag. That's not too different. I think being on cas-cli will help bring them all together in the long run anyways, but I don't see a huge value added from changing the CLI contracts as they have existed for a while. On the other hand, I see a HUGE advantage for standardizing the software framework with a flexible CLI framework like you've created to help that. My 2 cents. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer
