[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggestion for improving backend configuration...
From: |
Richard Frith-Macdonald |
Subject: |
Re: Suggestion for improving backend configuration... |
Date: |
Thu, 28 Jun 2012 08:34:50 +0100 |
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