Create a specification and Interfaces

[LeanderK]

The current state of affairs is rather messy.

Often our implementation is our specification and things are undocumented. We should write a real specification and separate specification and implementation. Also to shrink the project-size we should move the implementation to a separate Project (IzouAddonSDK). To make this work we would have to modularize various Parts of Izou. Out current Dependency-graph is horrible, every module has a dependency on every other module. This leads to a more fragile system wich is hard to maintain and not easy to test.

There are various benefits:

• the project would gain simplicity: application logic is in IzouAddonSDK, izou-logic is in Izou
• the modularization would make Izou more robust and easier to test
• higher abstractions in izou: the specification would allow to predict behaviour and not having access to the AddOn-Logic makes more quick & dirty solutions difficult
• programming against interfaces (I don't think i have to explain why this is very good)
• Reduce code smell & bad implementations (!!!! one of the most important points)
• define Izou
• provide a deterministic behaviour for addons
• makes backward compatibility easier (AddOns could provide a tag in the manifest which App-SDK they are using)
• makes the project easier to understand for newbies because 1. they can read the specification 2. the codebase for the AddOnSDK is smaller

Drawback:

• breaks backward compatibility

The goal of this proposal is:

• seperate Izou and Izou Addons
• specify Izou and IzouAddonsSDK
• improve the overall code-quality by refratoring
• modularize
• create interfaces for all specifications
• create higher level abstraction in Izou

Release:
Everything we add to Izou makes this proposal harder to implement. Therefore it is rather urgent. The problem is that it breaks backward compatibility, so the targeted release is at least 2.0. Also it is much work so, which should not to be underestimated. This proposal is crucial for a serious project of this complexity, so before we should not loose sight of it.

[LeanderK]

@jundl77 comments?

[jundl77]

yes yes I saw it, definitely something we need

[jundl77]

Actually, I think this should be our big goal for v2.0, with maybe a couple more addOn's

[LeanderK]

nearly finished! there is only the properties-package left and the few additions to the classloader! :)
@jundl77 can you tackle it?

[LeanderK]

more precisely:

• properties-package:
  • rework PropertiesAssistant & Container (it think we should re-implement the container from scratch (proxy-pattern), a really, really simple listener api would be neat, e.g. container.registerChangeListener(....))
  • update API in Context (also extract the interface)
• Classloader:
  • there must be a SDK version number in the manifest, we can simply read it and then hook in the right class loader (IzouPluginClassLoader, just after it tries the lib classes), if its not there you can just load the latest
    *the question is where to put the SDK-classloaders. You can pass them from Izou, or create it when you instantiate the Addon-Classloader (it think this is better, it also reduces cross-project dependencies)
• party because we have 2.0 :D

[jundl77]

haha I like the party, and 2.0 haha big steps fast 💃

[jundl77]

yes the properties container is bad, ill turn it into a listener, actually we already have a listener for property files, maybe we can combine them :D