X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 9 Aug 2016 16:21:53 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] [pcb-rnd] release 1.1.0
In-Reply-To: <20160809132822.GO12988@foo.stuge.se>
Message-ID: <alpine.DEB.2.00.1608091606210.7286@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1608060637530 DOT 7286 AT igor2priv> <20160808102438 DOT 12df1886 AT jive> <alpine DOT DEB DOT 2 DOT 00 DOT 1608081118350 DOT 7286 AT igor2priv> <CAC4O8c-h9OjTRORUzUZ1H34JNDwqzZ=EOdOMOjY=OyhdtybcfQ AT mail DOT gmail DOT com> <362971c9-89a9-d628-21ce-4e18349cf95a AT prochac DOT sk>
 <20160808225137 DOT GN12988 AT foo DOT stuge DOT se> <alpine DOT DEB DOT 2 DOT 00 DOT 1608090437590 DOT 7286 AT igor2priv> <20160809132822 DOT GO12988 AT foo DOT stuge DOT se>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk



On Tue, 9 Aug 2016, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] wrote:

> gedau AT igor2 DOT repo DOT hu wrote:
>>> Are the file format plugin systems in pcb and pcb-rnd compatible?
>>
>> Nope.
>>
>>> If not, why not?
>>
>> My goal with the io_* plugin was not only to allow multiple file
>> formats but to make them plugins.
>
> I understand.
>
> How does it look if we ignore the plugin implementation(s) and only
> look at the semantics of file format abstraction?

There is a plug API in the core: it's mainly a struct that has function 
pointers. There's a linked list of the structs, each file format handler 
registers one (or more). All calls go through these structs.

For import and IO load, all plugins are quieried first whether they think 
they could handle the request. They return a priority value: how much they 
think they are capable of doing it.

The highest prio struct gets the job and the actual load (or import) 
function of that one is called.

In case of IO the choice is also saved as global state so if the user 
later initiates a "save", it will go through the same struct so the user 
gets the same format ("save as" is obviously different).

>
>
>> Pcb-rnd has an improved plugin system in place
>
> Cool, but orthogonal to abstracting file formats.
>
> The file format abstraction can and would be useful to have
> compatible between mainline and pcb-rnd IMO.

Whether this could work also depends on the policy. I am not sure what 
exactly mainline has for this, but reading the code I have the impression 
at some point it wanted to narrow down the API in the plugin -> core 
direction (sorry, plugins _do_ matter here, it's part of the API 
question). This means a plugin should use any code from the core, but 
there should be dedicated API exporting the functionality intended to be 
used. Again, I am not sure this was intentional. Anyway such a narrow 
API does good for external plugins because you can more freely change 
internals without breaking compatibility with the plugins.

In contrast, in pcb-rnd I have "core plugins" which should evolve together 
with the core, thus I intentionally don't attempt to narrow the core 
plugin -> core API. Thus a pcb-rnd core plugin depends more internals 
of pcb-rnd than an external plugin would depend on the internals of 
mainline (if the API narrowing is implemented properly).

This generally means we can't just take a plugin from one project and drop 
it on the other and expect it just works.

>
>> I especially don't think that big infrastructural changes like the
>> improved plugin system (that heavily depends on the build system)
>> would ever hit mainline.
>
> I'm much more focused on the semantics and behavior of the file
> format abstraction. Sorry, I could have made that more clear by not
> mentioning plugin in my original message.

I really think the plugin part can not be cut off of this: the API is 
closely related to whether you are a plugins or part of the core.

Btw, I originally checked the mainline patch earlier this year. I even 
started to merge it in pcb-rnd. Then I figured it didn't play well with 
the existing plugin mechanisms in pcb-rnd. This (together with plugins 
depending on internals making it impossible to move plugins between the 
projects) led to the decision that I implemented pcb-rnd-native plugin 
thing instead of the mainline-native IO patch.

Regards,

Igor2