Plugins menu

Robert Brenstein rjb at rz.uni-potsdam.de
Thu Jan 8 13:00:20 EST 2004


>On 1/2/04 1:07 PM, Richard Gaskin wrote:
>
>>   Questions:
>>       - Should it create the folder autimatically, throw an error,
>>        or ask the user if it should create one?
>
>None of those, I don't think. It should probably just return empty, 
>which would act like a silent error. The calling handler can test 
>for "empty" and act accordingly.

I think it should simply create the folder, although the folder 
should really be already in the distribution.

>>
>>      - Should functions in MC' backscript be prefixed with "mc"?
>
>Don't think so. They aren't that way now.
>

The question should be then whether this should not become a rule to 
avoid potential conflicts with user handlers and rev.

>>- If no plugins are in the folder, rather have than no menu at
>>   all it has one diabled item, "None"
>>
>>   Question:  Should that be more descriptive, some think
>>   "No plugins installed", or would that be too verbose?
>
>"None" is okay with me. So is "No plugins" as someone else suggested.

I think "No plugins" sounds a tad better and is not much longer.

>>Process questions:
>>
>>- When making changes to the MC IDE, should the person making the
>>   contribution post a note here to avoid potental version conflicts
>>   with someone else who may be doing the same?
>
>It would be a courtesy, and probably helpful.

In lieu of not using any formal checkout procedures, I'd think that 
it is quite important unless a list of who is working on what is 
somehow maintained on the web site.

>>
>>- How can we clearly distinguish the latest release build from test
>>   versions for review in the Yahoo groups files section?
>
>Good question. I draw a blank here. An appropriate suffix or extension, maybe?

Wouldn't this be a job for the ide-specific version number that we 
discussed early on? I mean we discussed adding a function but that 
same version could be appended to the file name, like in 
mctools.252b2.gz (me thinks .mc can be omitted for gz files since the 
file inside has it). The potential problem with the date arises when 
more than a single file is posted the same day (although a letter can 
be appended there). However, we are also likely to have files posted 
for review that are not formally release builds (as in alpha, beta) 
and then date-initials will work better. What may be helpful is to 
have some annotation on the web as to what is new/different about 
each file.

Robert Brenstein


More information about the metacard mailing list