Re: Suggestion for improving backend configuration...

[Richard Frith-Macdonald]

On 28 Jun 2012, at 02:55, Gregory Casamento wrote:

> Fred,
> 
> What I had thought is that the initializeBackend method could use information 
> from the info.plist for the bundle to determine what the concrete subclass 
> for the context and server are.  This would be trivial to implement.   
> 
> It seems to me that it should be possible to compile a backend without 
> modifying the logic I quoted in the previous message.
> 
> Wouldn't it be also better to build the common parts of the backend into a 
> framework so that "third party" backends could be written without requiring 
> direct changes to GNUstep code.
> 
> This is just something I was thinking about that could be useful which is why 
> I asked for thoughts regarding it.  It is not a fully formed idea, so there 
> shouldn't be any puzzling over it, I was asking people to brainstorm a little 
> with me.

I agree that it would be quite nice (in the sense that it feels more 
elegant/pleasing) to have the backend class determined automatically without 
having to set a user default.

Another option would be to remove the GSBackend.m source, and have it generated 
automatically when you build a backend ... then the GSBackend +initialize 
method would be different for each backend and would initialize the correct 
classes.

We could also abolish all these separate names for the context class and just 
use a single name (as I understand it, a backend bundle only contains one fo 
the context classes anyway.

Or we could add a [GSBackend+contextClass] method to return the correct 
context, and backend developers would just override that in a category.

That being said , as Fred points out, all this is *in* the backend source ... 
so any third party writing a new backend can set it up any way they like anyway 
and wouldn't be modifying any gnustep code (they'd be replacing the gnustep 
backend code with their own).

Of course, you are also right that minimising the work people would need to do 
is a good idea, but that probably means wholesale restructuring to try and 
extract common functionality