« FileMaker meeting in … | Home | MBS FileMaker Plugin,… »

Library vs. Plugin

At the Xojo conference here in Houston Xojo Inc. announced a couple of upcoming features for Xojo. You can read details on the Xojo blog, Bob's blob or soon in Xojo Developer Magazine. One of the news in the creation of plugins in Xojo. Let's call those a library as you bundle Xojo code with resources into an archive. And as a few people asked me how that would affect me or whether I will support them, so here a few details:

First what is a Xojo Plugin currently?
Well, a xojo plugin currently is a zip archive with file extension .xojo_plugin. You can rename it to .zip and unpack it if you like to take a look inside youself. What you find are a couple of folders with various compiled libraries inside. Those libraries come per platform, so we have there DLLs for Windows, dylibs for Macs and shared objects for Linux. Current MBS Plugin have 8 different variants included.

To write such a plugin, you take a native compiler for your platform, write some C, C++, Objective-C or assembler code. You can include static libraries in your plugin and fully use all the features in the C compilers offer you. The libraries include the Xojo declarations and register them at runtime, so the IDE loads all plugins and queries them for the declarations.

What is a Xojo library?
Not sure how Xojo Inc. will call it exactly, but as far as I know it will be a new type of project. There you can include all stuff you currently have in projects like modules, classes and windows. Than you press build button and it will compile them all and write intermediate code into a new file. This should include resources like images and native libraries written in C/C++.
So you can add a library to a project and when compelling the Xojo IDE will include the library parts in the normal build process.

Convert Plugins?
Depending on how library projects will be designed, it may be possible for me to write a converter for my plugins. An application which can read my plugin definitions and generate the wrapper classes. Each method there would have a declare line to call the underlaying C function. I am not sure how well this would work and whether the overhead is worth it. Could be that it is easier and more convenient to just keep the plugins as they are and just provide newer stuff in the new format.

Uses for Libraries
We all have common code which we currently include in all projects. This common code can be moved into a library project and be prebuilt. This way the build process of our normal apps should be faster. Although when debugging the project, the debugger may not be able to step into our own library!

Next you want to bundle some code and sell it. Plugin vendors like me may be able to finally deliver iOS compatible plugins this way. At least precompiled is better protected than encrypted classes which have been breached before. Selling libraries could increase the number of vendors and help to get more third party controls into the Xojo store.

Possible Problems
There are a couple of problems coming which needs to be resolved:
  • First what happens if you add a library with a window to a console project?
    Probably this will cause errors and some libraries must have flags and #if set to work well.
  • How can libraries be compatible to several Xojo versions?
    The intermediate code from LLVM and the file format used by Xojo may not be forward or backwards compatible. Also calls to the framework may change, so newer library may miss a function in the Xojo runtime if used in an older version of the Xojo IDE.
  • How do we handle conflicts within the libraries?
    Class names may be declared in different ways. While I hope we can do libraries without putting them into namespaces, it would be nice if the library user could optionally add a namespace in order to resolve conflicts.
  • Would libraries include function names, so we see that in stack traces?
  • Can we debug into the library if we have the library source code?
    Maybe we may need a library format including source code for debugging, at least for home made libraries.

So let's see what gets released later in 2017 and maybe refined in upcoming releases in 2018.
07 10 16 - 15:47