Ok, kind of a "techie" question (more than one really)..

[Steven Hancock]

First, about plugins.. are we allowed to write our own plugins? If so, how? What I want to do is for my own personal use, I wouldn't be selling it or anything.

Second question, kind of relates to the first (but I suspect it could also be done without a plugin).. here's what I want to do:
I have a script I'm writing, it will be a PHP script encoded with IonCube and I need it to call back to a server to verify licensing. Licensing will be domain based, and I'm wondering how hard it would be to set something up where the customer enters their domain name on the "thank you" page and gets a license code automatically generated for them (think how we all generated our DELAVO licenses, something similar to that process). I'm going to code the licensing server myself, I have no need to spend the extra money on IonCube's licensing solution (I'm just using their online encoder), so I'll have full control over the entire process if that makes things any easier.

[Hue Anne]

I believe you are allowed to write your own plugins, but there will be no support for a broken Delavo due to a custom plugin (Not written by the Delavo team).


I think these terms apply to Delavo plugins.

- Include all the related copyright and trademark notices
and a disclaimer that will clearly state that we are not
responsible for the outcome of the use of this plugin
by others.

- Submit it to us through the helpdesk so to number it
and keep a record of it.

Please wait for someone more higher up to answer this question for sure ;).

[Steven Hancock]

Thanks, that sort of answers my question, but still doesn't cover the "how" on the technical side of things.. meaning, what are the requirements to make it actually "plug into" DELAVO? I think it's probably safe to assume it needs to be written in perl, I don't know much perl but for my purposes I think I can manage because all I really need to do is add something to a database and then let my PHP code handle it from there.

Is there any kind of documentation for this anywhere? A "blank" template would be nice not absolutely needed if I can get some kind of documentation or at least a brief explanation of what code I need to write to make it "plug into" DELAVO.

[Hue Anne]

There is no documentation on how to write unofficial plug-ins.

Nor will I be writing any. :)

Donna

[Steven Hancock]

Ok, so if I understand correctly.. we're technically allowed to write our own plugins, but really we can't unless we want to spend a lot of time either reverse-engineering an existing plugin or reverse-engineering DELAVO itself (a practice that most software licenses prohibit). Which basically means (unless I'm wrong and the DELAVO license allows for reverse-engineering) we're really not allowed to write our own plugins.

From the license PDF that came with my copy of DELAVO:
a. Disassembly, decompilation, or reverse-engineering of the Software is prohibited.

So without documentation it would be a violation of the license for me to write a third-party plugin, even for my own use, and regardless of whether it's otherwise "allowed."

[Hue Anne]

There is an API plug-in that will become available
but I don't know when.

And there is documentation on how to use API but
there will be no documentation on creating a plug-in.

You are not allowed to reverse engineer Delavo or
an official plug-in. Doing so may get your license revoked.

Donna

[Steven Hancock]

That was my point.. supposedly we're allowed to write our own plugins.. but without documentation and without reverse-engineering it's impossible to write our own plugins, so why say it's allowed in the first place?

[Brian Collins]

That was my point.. supposedly we're allowed to write our own plugins.. but without documentation and without reverse-engineering it's impossible to write our own plugins, so why say it's allowed in the first place?


Steven,

A few of us have had our plugins for Fantasos written for us by John's team and we grouped together to keep the cost down.

Also there is/will be an api available to interrogate the Delavo database for customers.

Brian

[Hue Anne]

Steve

As I said there is an API plug-in that will become available
in the future.

First of all, I am not a programmer so I would not know how
to create a plug-in. And if I don't know how to create a plug-in,
I can't write about.

And even if I was a programmer, because I am associated with
John and am the only person licensed to write the "Official"
documentation, I wouldn't write a manual on how to create an
unofficial plug-in.

Since John will be allowing people to write unofficial documentation
maybe someone will write how to do this. But one of the problems
with unofficial documenatation is that the accuracy and quality
is not guaranteed. And I have seen some really awful documentation
that was submitted to John from people wanting to write stuff for
Fantasos.

Donna

[Steven Hancock]

If someone were to write unofficial documentation describing how to write plugins, that would mean (lacking official documentation) they must have reverse-engineered Delavo or one of the official plugins. So once again there's the catch-22.. you're allowed to write plugins, but nobody is going to tell you how to do it and you're not allowed to figure it out on your own through reverse-engineering.

At any rate, I think I've found a solution that doesn't require a plugin (but it isn't exactly the ideal solution for what I'm wanting to do.. and I might just end up using DLGuard for this project rather than DELAVO since the process for writing third-party DLGuard plugins is somewhat documented and I really need to "integrate" with the sales/delivery process as much as possible).

[Steven Hancock]

Brian, your solution would be great if I wanted something more general purpose, but what I have in mind is a licensing system specific to a product I'm creating. I wouldn't want to share that any more than I'd expect John to share his Fantasos/DELAVO licensing system, security through obscurity isn't always the best way to keep something like that from being cracked but at least it provides an added layer of protection. I also don't think I should need to bother John and his programming team with something that's going to be specific for my needs. Like I said if it was something more general purpose or wasn't something that I planned on keeping to myself as a sort of "trade secret" your solution would be perfect, but in this case that probably wouldn't be the best way to handle it. Plus I'm sure right now John and his programming team are busy getting the plugins and the next version of DELAVO ready to go (I recall him saying something on Warrior Forum about a version 1.1 to be released soon), so I don't know how long I'd have to wait if I went that route.

Anyway, like I said it's not really the most ideal solution (in my mind at least) but I've figured out how to do what I want to do. The product license will be domain based with a form on the thank you page to enter a domain name. Rather than building a plugin to take care of this for me, I'll just handle it all in my PHP code. All I need to do is put a form on the thank you page (or better yet, an iframe, that way if the product license is already registered I can show the license number instead of the form), and use a template tag to pass the Sale ID into the form through a hidden form field. That way, since I know my own DELAVO database password I can just execute a simple MySQL query inside my PHP code to check for a valid sale and make sure it wasn't refunded. Since the database structure is plainly obvious to anyone with PHPMyAdmin (basically anyone whose web host has any modern control panel like cPanel or Plesk) I don't think that could be considered "reverse engineering" like what I would have had to do if I wanted to write a plugin.. lol

That should give me the kind of integration I need, at the expense of having to jump through a couple extra hoops setting it up.

[Brian Collins]

Hi Steven,

A man after my own heart - as someone once said to me - there is always at least one solution to every problem :)

Brian

[Steven Hancock]

Yeah Brian, there's always more than one way to solve a problem.. the solution I came up with isn't really ideal for what I'd like to do, but it'll work for now until there's some kind of support for third-party plugins. I really would have liked to integrate a little "tighter" with the whole sales and delivery process, but it should work at least until I can figure out a better way.

I do have one more question for Donna or anyone else who works for John, just so I know in case I do ever need to write a plugin in the future.. I think I might have found a possible solution to that too and want to know whether or not John and his people would consider it "reverse engineering" or if it's a legitimate way for me to figure it out.

Since the script is written in perl and perl is an interpreted language, the source code is available for inspection.. we can look at it just like any other text file, it's not compiled in any way. I notice a lot of the source files are "obfuscated" to make them difficult to read, understand and modify. However, there are a couple files in the kit.jin.plugins directory that are not obfuscated in any way, they're plain easy to read perl (or as easy to read as perl gets anyway.. lol). If I were to study those and use what I learn from them as the basis for writing a plugin, would that be ok or would it still be considered "reverse engineering"? This isn't exactly a hypothetical question, I enjoy programming and I can see myself wanting to write a plugin at some point even if I don't need to go that route for my current project. I haven't attempted to decipher or reverse-engineer the code in any way (and especially not the obfuscated files, I couldn't make heads or tails of those if I wanted to lol) but this is just what I've managed to gather from a very quick glance at a few files in my cPanel file manager.

And Donna, just so you know, I wasn't trying to argue with you or disrespect you in any way.. I'm just really trying to understand how it is that we're supposed to be able to write our own plugins (which I've been told we're allowed to do) when there's no no possible way (unless my idea above is ok with John and his people) for anyone to learn how to write a plugin without documentation or reverse-engineering.. which would also automatically exclude the possibility of third-party documentation, since that would have had to be learned through reverse-engineering as well (again, unless my idea above is ok). I understand that you're not a programmer and wouldn't be able to write such documentation yourself.. as far as not writing it if you could because of your association with John, that part I'm not too clear on unless he's expressed some desire to not have people writing third-party or "unofficial" plugins. Personally I would think the availability of more plugins (official or otherwise) only increases the perceived value and usefulness of the core script, which increases the overall value of Turbo Membership (the only way to get the script after the giveaway ends) and creates a larger market for all plugins (again, official or otherwise).. but maybe I'm missing something lol