kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

Yeah, not loading the whole file. It would be a static function in
each plugin that just sort of tests a wee bit,
binary != xml != sexpr != (whatever the old kicad format is) and each
of those could be differentiated easily with 200 bytes. Most binary
ones will also have magic in them for identification anyway.

as far as i can tell it could be done 3 ways

- by passing the file (which would most likely be slowest due to
open/closing of the file for each plugin
- an arbitary arbitary amount of data read into an array/string and
then passed to each saying do you understand this much.... (this would
work 99% of the time) unless it came down to very small changes and a
very crappy file format that didn't have versioning early/at all.
- memory map and pass the file that way to each importer plugin, this
would most likely be the most complicated solution, but would most
likely be one of the more accurate, and one of the most efficient,
however depending on file size this could cause problems (although
just like the former it could be limited to something reasonable).
This also wouldn't require reloading the file for the real board load
so shouldn't add any additional time to file load.

If we still use extensions i still think we need something like this
due to things like the eagle/old-kicad format's in which case the same
thing could be used but an additional field could be parsed to
CanYouHandleThis(FILE, HINT) with the hint being the extension, or
even overloaded to give multiple choices

On Fri, Mar 4, 2016 at 3:56 AM, Nick Østergaard <oe.nick@xxxxxxxxx> wrote:
> 2016-03-03 15:40 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
>> Are you considering attempting to load a file with each available plugin
>> until the correct one is found or they all fail?  That's not a very
>> elegant solution.  If you only have a few plugins this may be feasible
>> but what happens when you have 10 or 15 plugins?
>
> 10 or 15 plugins are not a lot. All they should do it sort of create a
> sanity check on weather or not the file is parseable. I think that can
> be determined quite quickly by the plugin. You usually don't need to
> parse the whole file. Often you can find a header in the file, that
> should give you a very strong indication on whether or not it is
> likely that the file can be read.
>
>>  This is one of the
>> reasons the fp-lib-table exists.  The fp-lib-table is not just a file
>> path resolution system.  It also handles associating the library (file
>> or folder of files) type with the correct plugin as well as any optional
>> parameters the plugin requires to perform it's job.  Relying on file
>> extensions is always going to have it's issues.  Unfortunately we are no
>> closer to a file system with file metadata then we were 30 years ago
>> when the powers that be figured out the whole file extension concept was
>> broken.  I wouldn't hold my breath on this being fixed anytime soon.
>>
>> On 3/2/2016 5:19 AM, Simon Wells wrote:
>>> Handling multiple plugins would be annoying and probably a whole
>>> different discussion, but it should really only be an issue when user
>>> plugins are possible if sanity checks are done properly. And it would
>>> most like have to be a user setting or i have no idea of a better way
>>> of doing it
>>>
>>> On Wed, Mar 2, 2016 at 10:40 PM, Nick Østergaard <oe.nick@xxxxxxxxx> wrote:
>>>> 2016-03-02 9:21 GMT+01:00 Simon Wells <swel024@xxxxxxxxx>:
>>>>> After looking into and discussing
>>>>> https://bugs.launchpad.net/kicad/+bug/1551628 with nick i am not sure
>>>>> the filter is the best way of advising kicad of which plugin to use
>>>>>
>>>>> I was thinking the best way to solve this would be for each of the
>>>>> plugins to have a static
>>>>>  "bool CanYouHandleThis"
>>>>> function (obviously with a better name) and when a file is loaded each
>>>>> of the plugins are checked to see if they understand the file,
>>>>
>>>> Yes, I think this is a proper way to do this. After all, it is the
>>>> plugin that knows if it can parse the file, so having a
>>>> CanYouHandleThis to sanity check the file or whatever it does to say,
>>>> "Yay, I can handle this file!", would be a good idea, it could
>>>> possibly also be used to do some better error reporting to the user.
>>>> Say; the user tries to open an eagle v5 .brd file which is not
>>>> supported, it could possibly detect the version type of the file and
>>>> import the user that the file he is trying to open is v5 and only v6
>>>> is supported for example.
>>>>
>>>>> With each of the responses if they are all no, then a error can be
>>>>> reported, and for any that are yes the loading can then be handed off
>>>>> to it/them (if dynamic plugins are enabled at some point in the future
>>>>> (which you would really need some sort of what can you read interface
>>>>> anyway) then you may get to the point where multiple can handle a
>>>>> single file)
>>>>
>>>> If multiple plugins can handle a file, how would you handle that
>>>> situation seamlessly?
>>>>
>>>>> This would allow the user to not have to set the filter which i am not
>>>>> sure many people would think as the problem anyway as far as i am
>>>>> aware its not the normal method for setting what type a file is. And
>>>>> also move away from blindly trusting extensions
>>>>
>>>> Blindly trusting extensions is indeed problematic as we already have seen :)
>>>>
>>>>> Thanks
>>>>>
>>>>> Simon
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp