Mail Archives: geda-user/2016/08/09/10:13:47
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
- Raw text -