DeleD Community Edition

Jeroen · Posted: Thu Jan 06, 2011 4:33 pm Post subject:

Ah, fact is that there aren't many plugin coders out there, due to the fact the plugin architecture doesn't suit most of the needs of coders out there. One of the main reasons for you to create a better one in the first place. Wink

Also, not all coders are also technical designers. So... I think you won't get much response at first until there's actually something to work with and people start to see the value of the new architecture.

Perhaps it's a good idea to dive a little deeper into the API stuff. Can you tell us a little more about what you have in mind?
_________________
Check out Figuro, our online 3D app! More powerful 3D tools for free.

chrisu · Posted: Thu Jan 06, 2011 5:18 pm Post subject:

AWM Mars · Posted: Thu Jan 06, 2011 7:32 pm Post subject:

Jeroen · Posted: Sat Jan 08, 2011 8:37 am Post subject:

Just a few random remarks & questions:

chrisu · Posted: Mon Jan 10, 2011 9:32 am Post subject:

Starnick · DeleD PRO user Joined: 28 Jul 2007 Posts: 611

Heh this sounds a lot like what I've been reading about with SlimDX - "export interop". There's a danger when exporting objects between libraries (especially unmanaged objects to a managed environment), since the data can change without your control at anytime. You can't cache anything that isn't invariant. It certainly would be doable, but probably more trouble than what's it worth. A few DLL exports that a C# plugin (or other .NET languages) could use via P/Invoke would work just fine.

This API sounds more like a layer between DeleD and a plugin where the plugin hooks into the API, and the API hooks into DeleD (basically events and callbacks). Rather than some sort of job-queue thing.

E.g. For a registered plugin that adds a new tool to the geometry tools, when deled loads the plugin, the plugin sets a hook to the API. When deled sets up its geometry toolbox, it asks the API's for any registered tools, the callback gets activated, pertinent data gets sent across. Whenever the user uses said tool, the plugin gets notified and performs the job.

chronozphere · Posted: Tue Jan 11, 2011 8:46 pm Post subject:

Hey dudez!

I'm glad I noticed this discussion here. Smile

I didn't read the whole thread, but I noticed the diagram. It looks pretty good to me. Nice separation of modules. Go for it!

I do have one concern. Me and Paul Nicholls have been working on our paths too, but we didnt finish it. I hope the svn repository is in "usable" state. If not, someone could reverse some of our changes, or make a new branch.

If I understand this right, you will make this new interface work as a plugin into the existing interface?
Or will you make a new plugin-interface and create an "adapter" DLL for backward-compatibility?

I'd encourage you to take a good look at the deled source before planning alot of features. Make a small start by introducing a few functions to send/recieve vertices and expand the API from there.
It's tempting to do a top-down design, but when you do that, you will realize more that it will take a long time before it's finished.
Starting at the bottom and making decisions as you move forward is likely to be a more satisfying method. Wink

If you have some questions about the DeleD codebase or Delphi in general, don't hessitate to contact me. I may be able to assist you there. Smile

Good luck!

chrisu · Posted: Tue Jan 11, 2011 10:43 pm Post subject:

@Starnick: I've thrown the queue-thingy overboard. It's also doable without them and your general concerns about them where right. However, it was just an initial idea.

@chronozphere: I didn't touch the codebase yet, I just checked out the code as described in the WIKI with the plan to generate a package (or patch ... can't remember) which I'll give to you. If that aint right please gimme a note.

The old plugins will continue to work and it will also be possible to use the old interface - but without API. The API itself will be a "simple" DLL whose exported functions will be wellknown by DeleD. DeleD will therefore have a very specifical, "private" communication with this DLL. Any new plugin will initially get connected with DeleD and the API-DLL. So some kind of triangle-relationship Wink

I only hope none of those is gettn jelous. Smile

Thx for your advices, I appreciate them.

Cheers,
Chrisu.

chrisu · Posted: Wed Jan 12, 2011 3:55 pm Post subject:

I made a pretty detailed sketch today which focuses the components and all necessary stuff of the new plugin-concept and it occurred to me that there might be also a way without the need for an extra-dll for the upcoming API. It should also be possible to implement the API-interface directly in DeleD. I think that this new evolution would make the whole concept much easier to handle and reduces complexity. I'm rather inclined to do it that "new" way. Any concernes?
I'll try to get the (updated) concept-sketch done as an image which I can post here. However, having this technical overview now gives me a positive feeling according to its "do-ability".

Cheers,
Chrisu.

Starnick · DeleD PRO user Joined: 28 Jul 2007 Posts: 611

chrisu · Posted: Wed Jan 12, 2011 8:37 pm Post subject:

chrisu · Posted: Mon Jan 17, 2011 11:13 pm Post subject:

Here's the big picture of the brand new plugin concept:

I hope it's kinda understandable. Wink

Feel free to ask!

Cheers,
Chrisu.

chronozphere · Posted: Tue Jan 18, 2011 5:37 pm Post subject:

Nice one!

Which program did you use to make this diagram. It looks really clean!

I like the way you pass an entire API to the plugin by using proc/method pointers. You could either pass an array of pointers and cast/assign them to variables in the plugin API file. You could also go for a record that contains the right methods.

The first approach is probably best because it is extendable. If you want to add an extra method to the API, just make the array bigger. If you choose for records, you will have problems when the plugin API changes.
Maybe you can use version numbers to check if the plugin and the plugin-interface are of the same version?

Also, Make sure that all those methods sufficiently check for errors. We don't want the plugin to mess up the internal state of deled.

Looking good. Keep up the good work! Smile

AWM Mars · Posted: Tue Jan 18, 2011 6:07 pm Post subject:

chrisu · Posted: Tue Jan 18, 2011 9:11 pm Post subject:

I've done the diagram with good old Visio.
The pointerarray is imho in many ways a good solution. You can i.e. initially make it 1000 elements huge, though there aren't so many API-functions. As the array is only transferred once (init) there's no big deal when it comes to performance. But that way it's rather easy to keep backward-compatibility without the need to re-compile any plugin when something changes in DeleD. If a function gets deprecated you just define the new one in the next free slot and the old one stays as long as needed keeping old plugins still functioning. An oversized array also has huge puffer-abilities - no grow -> no need to re-compile the dependencies.

One thing worth to mention. The EventRegistrator will get one or two arguments added to make it possible for a plugin to define some kind of call-intervall so that DeleD doesn't have to serve a i.e. viewer-plugin permanently with data that doesn't change that often.

The real brains is to define the list of events (though it's no problem to have that growing dynamically). So for that specific list we should do some sort of public brainstorming between us developers. Also we should create a list of API-functionality ordered according to their priority. Again something we might do together.

Thoughts?

Cheers,
Chrisu.