Hi Robbes!

Romain Robbes wrote:
> the next iteration (coming in the next few days) has this out, and  
> something I find neater is on a "developer" services package
> (along with refactorings, etc ...).
Ok, cool. BTW, if you're working on this, I have some suggestions:
1. There are some names that are too general, and I feel would be better 
made more specific. Requestors - if they are specialized for use with 
services, they shouldn't take up the general name. Another example is 
#findCategories as an extension to String - why shouldn't it find class 
categories? better to use a more explicit name such as the ungainly, but 
specific findServiceCategories. Any extension to commonly used classes 
should be especially careful about these things. And better to fix these 
things now, because once it is in the image, it will become very widely 
used protocol and become very hard to change.
2. The package has a lot of extensions. I haven't reviewed these, so it 
might not be relevant, but: Are any of these overrides? if so, please 
extract them to versions of the relevant 3.9a packages, so they can be 
MC merged in. Consider for the same treatment any extensions that are 
not overrides, but that are not Service specific.

Anyway, I'll have a closer look at your upcoming release, and we can 
hopefully include it soon after.

>> 3. There's a Requestor hierarchy. Having read most of the code and  
>> some of the comments, I haven't really understood their role in  this. 
>> Are these queries specific to code? or is this something  general to 
>> parametrize over how to handle requests that are usually  sent to the 
>> user? if so, what is its relation to those used in  various of the 
>> automatic installation tricks used for various  packages? is there 
>> parallel functionality in ToolBuilder?
> requestors are acting as a third-party between the model and the  services.
> a service asks the requestor for some information it needs, and the  
> requestor asks the model itselfs.
 >
 > This allows to have a BrowserRequestor, specialized to deal with
 > browsers, and then an OBRequestor inheriting from
 > it with only a few key overrides needed (such as getting the class
 > name, the selector name, etc).
So if I understand correctly, a Requestor subclass is aware that it is 
being invoked in some type of context (such as a browser, command line 
or menu), and supplies information to the service accordingly?

If so, have you looked at any of the GUI abstracting things I've 
mentioned above and seen if some integration is in order?

Daniel