Services for 3.9

Romain Robbes romain.robbes at lu.unisi.ch
Tue Aug 23 22:05:22 UTC 2005


On Aug 23, 2005, at 11:32 PM, Daniel Vainsencher wrote:


> I think we should put a Services framework in 3.9 as quickly as  
> possible, this is really important for improving the tools, and  
> would make simpler many packaging problems.  Are there candidates  
> other than Robbes Romain's? have people reviewed them? is there a  
> list of known issues?
>

Well I don't think there is any other framework available ...


>
> From a quick look at this one (Services-Base), I have the following  
> comments/questions:
> 1. It has a CLI thing that seems like it should be split off  
> (should be optional, while services should become common  
> infrastructure we can assume is there). BTW, the CLI looks pretty  
> neat (assuming keymapper is installed), but I dont understand what  
> the nextKeyStrokes: stuff does.
>

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 ...).


> 2. There's a couple of classes for subsets of the loaded code:  
> SubSystemNaviggation, and PartialClass. Probably useful for  
> specific services, not for the framework itself, so might be left  
> out (or not)
>

This goes in the developer package as well, hence is now out of the  
base.


> 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).

Cheers,
     Romain


>
> Daniel Vainsencher
>
>





More information about the Squeak-dev mailing list