Extension Testing

[James]

Of course.

[James]

Of course.

[vortex2]

Two ideas to protect the extensions:

A) Code a system where the exensions expire.

B) Make it so the beta extensions can't build exe/ccn files <img src="/center/images/graemlins/wink.gif" alt="" />.

I wonder if it is possible to distribute just the release version of the beta extension, and make it so it can't be used at runtime?

Some ideas to start with:

A) First remove everyone who doesn't own the full version.

B) When you start the pilot perhaps only allow 30-40 people to join it during that period.

I think it would be good if we could somehow tie the beta extension to the person it was given to. If we could do that, then tracing leaks would become much easier (especially if we didn't tell them :P).

[vortex2]

Two ideas to protect the extensions:

A) Code a system where the exensions expire.

B) Make it so the beta extensions can't build exe/ccn files <img src="/center/images/graemlins/wink.gif" alt="" />.

I wonder if it is possible to distribute just the release version of the beta extension, and make it so it can't be used at runtime?

Some ideas to start with:

A) First remove everyone who doesn't own the full version.

B) When you start the pilot perhaps only allow 30-40 people to join it during that period.

I think it would be good if we could somehow tie the beta extension to the person it was given to. If we could do that, then tracing leaks would become much easier (especially if we didn't tell them :P).

[turboferret]

[]B) Make it so the beta extensions can't build exe/ccn files . [/]
Easy, as I experienced when I tried to build an application with an extension created with the old SDK where GetDependencies were defined

LPCSTR* WINAPI DLLExport GetDependencies(mv _far *mV, LPEDATA edPtr)
{
	return NULL;
}

if you try to build an application with this function added in the .def file and defined like this, MMF2 will complain when trying to build a standalone app.

so I would use something like this

#ifdef BETA_EXT
LPCSTR* WINAPI DLLExport GetDependencies(mv _far *mV, LPEDATA edPtr)
#else
LPCSTR* WINAPI DLLExport GetDependencies()
#endif
{
	return NULL;
}

[turboferret]

[]B) Make it so the beta extensions can't build exe/ccn files . [/]
Easy, as I experienced when I tried to build an application with an extension created with the old SDK where GetDependencies were defined

LPCSTR* WINAPI DLLExport GetDependencies(mv _far *mV, LPEDATA edPtr)
{
	return NULL;
}

if you try to build an application with this function added in the .def file and defined like this, MMF2 will complain when trying to build a standalone app.

so I would use something like this

#ifdef BETA_EXT
LPCSTR* WINAPI DLLExport GetDependencies(mv _far *mV, LPEDATA edPtr)
#else
LPCSTR* WINAPI DLLExport GetDependencies()
#endif
{
	return NULL;
}

[Novabrain]

These are good ideas! Great stuff.

First, I am hoping that we can get the first PBP tested and published by the Holiday Season. Over here, that starts with Halloween, then Thanksgiving, and Xmas/etc.

If we can protect and restrict the Beta extensions as proposed above, then the next step is to start the pilot program. Administering it is the trick. I like the ideas about limiting the number of participants, and we certainly would want to restrict it to actual, registered users.

In order to verify users, Jeff would have to be involved and I am not sure how he would want to handle that. It would be nice if there were either a form that would allow them to "sign-up" and then would chck their status in the CT Database, and spit out an email to the appropriate CT staff, or a code that could verify the fact.

Just thinking out loud. I know that Jeff wanted to eventually add a way for registered users to be recognized by the forum and allow for special areas, features, etc.

While sometime this month is going to be a long overdue vacation for me, I may start to put together the agreement and guidelines for the pilot testing program.

For now, please continue the discussion and brainstorm your ideas.

Also: Since we have lost some older members, it might be a good idea to put togehter a thread, or a pack, for new EDT that includes what they need to know. Things like the popup code, guidlines, conventions for naming betas, etc., and anything else.

Anybody who wants to take the lead for the new Apprentices is welcome to step-up and start a thread. I would prefer that the Journeymen who do lead tech be more like helpful managers and benefactors than bosses, as you already know <img src="/center/images/graemlins/wink.gif" alt="" /> We want to keep this enjoyable and laid-back.

[Novabrain]

These are good ideas! Great stuff.

First, I am hoping that we can get the first PBP tested and published by the Holiday Season. Over here, that starts with Halloween, then Thanksgiving, and Xmas/etc.

If we can protect and restrict the Beta extensions as proposed above, then the next step is to start the pilot program. Administering it is the trick. I like the ideas about limiting the number of participants, and we certainly would want to restrict it to actual, registered users.

In order to verify users, Jeff would have to be involved and I am not sure how he would want to handle that. It would be nice if there were either a form that would allow them to "sign-up" and then would chck their status in the CT Database, and spit out an email to the appropriate CT staff, or a code that could verify the fact.

Just thinking out loud. I know that Jeff wanted to eventually add a way for registered users to be recognized by the forum and allow for special areas, features, etc.

While sometime this month is going to be a long overdue vacation for me, I may start to put together the agreement and guidelines for the pilot testing program.

For now, please continue the discussion and brainstorm your ideas.

Also: Since we have lost some older members, it might be a good idea to put togehter a thread, or a pack, for new EDT that includes what they need to know. Things like the popup code, guidlines, conventions for naming betas, etc., and anything else.

Anybody who wants to take the lead for the new Apprentices is welcome to step-up and start a thread. I would prefer that the Journeymen who do lead tech be more like helpful managers and benefactors than bosses, as you already know <img src="/center/images/graemlins/wink.gif" alt="" /> We want to keep this enjoyable and laid-back.

[vortex2]

I think it is a plan, however we may need to take some steps to prevent people from lurking in the beta forums. What I mean by that is, perhaps their level of participation should determine their access <img src="/center/images/graemlins/wink.gif" alt="" />.

If it was possible I would like to see where the testers would have to contribute in order to stay in the group (where if they contribute a lot they would stay in the group perminately).

The reasoning behind this is that it doesn't make sense to keep people as beta testers if they provide no feedback. Keeping them around in that case is just serving to recreate the situation we have currently, but on a broader scale <img src="/center/images/graemlins/wink.gif" alt="" />.

In any case testing is a vital issue and I am glad that the situation is being thought out.

[vortex2]

I think it is a plan, however we may need to take some steps to prevent people from lurking in the beta forums. What I mean by that is, perhaps their level of participation should determine their access <img src="/center/images/graemlins/wink.gif" alt="" />.

If it was possible I would like to see where the testers would have to contribute in order to stay in the group (where if they contribute a lot they would stay in the group perminately).

The reasoning behind this is that it doesn't make sense to keep people as beta testers if they provide no feedback. Keeping them around in that case is just serving to recreate the situation we have currently, but on a broader scale <img src="/center/images/graemlins/wink.gif" alt="" />.

In any case testing is a vital issue and I am glad that the situation is being thought out.