I didn't noticed that I agreed to the Job/String duality. The point about dealing with tens of thousands of jobs as Job objects being difficult may be true, but I'm not sure I like the idea of handling them as String objects instead. A better approach might be to offer some kind of aggregate object, like those silly opaque iterators from the C binding.
I guess we need to look at use cases. The only reason I can see that you'd want to wait for 10k jobs and actually look at the returned list of jobs, is if you have a list of jobs you launched, and you're waiting for them to finish. Since the job ids are opaque, you can't shortcut the job ids with math. In order to keep a list of 10k jobs, even as String objects, you're going to have to take a clever approach. If
Good point. From my knowledge, only scripting languages such as Python treat string as scalar data type. I still like the duality approach, but the reasoning is a little bit weak. We need to discuss that again.
that you can find out the names of the jobs. Heck, maybe job name should be part of the Job object directly. In that kind of situation, an iterator would be exactly what you want, and it could be smart enough not to keep all the Job objects alive at once.
Iterators are no concept in DRMAA so far, which is good. Mapping everything to C (in a nice way !) is already painful enough .... Best, Peter.