Hi Jesse,
Jesse Barnum wrote:
>
>
> I've re-read the beginning of this thread, and I'm still not totally
> understanding the benefit of the unified function naming. As stated
> here:
>
> > This is needed if one wants to build a FileMaker template that takes
> > care of downloading the latest and greatest from the FileMaker
> > server, for all plug-ins currently installed, even when from different
> > vendors.
> > It can be more or less done using specific code for each plug-in or
> > brand, but it remains a pain to configure this, because it's always
> > done differently.
> >
>
> I have several questions:
>
> 1) Isn't it a simple matter to use the Evaluate function to call
> whatever the particular plugin's version # function is? How will
> using a <plugin>_VersionAutoUpdate naming convention simplify that?
> Is the idea that the name of the function will be derived from the
> name of the plugin, and therefore only have 1 field (the plugin name)
> to fill in instead of 2 fields (the plugin name and it's version
> function)? If so, what about plugins that have spaces in the name?
>
The main idea behind this discussion, from my point of view anyway, is
to provide to end-users an easy-to-use function for returning an "Auto
Update-friendly version number". If the majority of plug-in vendors
joined forces and implemented this sort of functionality, then end-users
would be able to take the concept behind their auto-update scripts and
use that concept with any plug-in.
The idea of the "<plugin>_VersionAutoUpdate" function name is based on
the fact that most plug-ins use the "<plugin>_<function>" scheme for
naming their functions. While I know not everyone uses that scheme,
it's still a good idea (and even used to be "required" [I use the term
lightly] by FMI in the FM4-6 days). It's not meant to be derived from
the plug-in name for use in an Evaluate() or anything (as far as I've
gathered from this discussion). Trying to derive it for just about any
of our plug-ins would fail anyway. (For example, our product named
"SMTPit Pro" would be using "SMTPit_VersionAutoUpdate" as the function
name.)
So, to sum up this answer, basically what we are saying here is to have
a function where the main function name is "VersionAutoUpdate", but with
whatever function naming scheme you currently use for your plug-ins.
So, with that in place, end-users can scan your functions, find the one
that says "VersionAutoUpdate" and know that it returns an "auto
update-friendly version number".
> 2) Isn't the actual format of the returned value immaterial, as long
> as GetAsNumber does a correct comparison?
Sure, if GetAsNumber can convert it into a number that compares
correctly. Again, though, the idea is conformity for a number of reasons:
- Most plug-ins use more than one decimal place for a version number.
While GetAsNumber ignores extraneous decimal points, you wouldn't be
able to tell the difference between 4.12.2 and 4.1.22 for example.
- A lot of version functions also return text like "SMTPit Pro
v.4.1.2". As mentioned by Kent, sometimes minus signs are used which
make the number negative.
- By having a unified version number scheme, if someone needed/wanted
to figure out exactly which update version of a plug-in they had
installed, they could use MiddleWords( Version ; 5 ; 2 ) for example.
- Since a version number is used on the Server as a folder name,
having a unified version number scheme would again make it easy for the
end-user to set up the folders on the server
>
> 3) What about the license code and registration functions? Are we
> planning on standardizing that? If not, then what's the benefit of
> standardizing the version name function?
I'm really not sure why this would be related. Standardizing the
version function here is to aid in using Auto Update to download new
versions of plug-ins. If the plug-in had never been installed on a
client machine, then I could see where it might need to be registered,
but it's not an every-time-the-solution-is-opened sort of deal (at least
not with our plug-ins). Besides that, trying to get every plug-in
vendor to use the same type of license code registration would be next
to impossible.
And finally, standards are meant to be broken and outright ignored.
This whole discussion was more or less spawned by people who are tired
of every plug-in doing it differently and getting frustrated by having
to make all these complex calculations for each individual plug-in just
to see if one version is newer than another. A few of us decided to try
to make a standard to make it easier on end-users, but it's by no means
law. If you don't happen to see the benefit of doing something like
this, then there's no reason you have to. I'm not trying to be rude or
anything by saying this, just trying to state the facts of this discussion.
I hope this helps,
Jake
--
Jake Traynham
Owner, CNS Plug-ins
http://www.cnsplug-ins.com/
smime.p7s (3K) 
