Re: Library Modules and Library Loaders
Re: Library Modules and Library Loaders
- Subject: Re: Library Modules and Library Loaders
- From: Philip Aker <email@hidden>
- Date: Tue, 14 Sep 2010 07:37:15 -0700
On 2010-09-05, at 19:21:21, Tetsuro KURITA wrote:
>> What I want is a standard file format for modules. I didn't intend write any code to have this done.
> I guess your standard file format menas :
> * Appending additional entries into the Info.plist
Hi Tetsuro,
What I mean is that it would be better for users to have a file format describing libraries so that when using different library loaders, they can have the same way of specifying the files they wish to have loaded. RTF is a standard file format that word processors can use. So the modules.plist can be used by any library loader or library manager because it will be a standard format.
The latest version of ModuleManager is here: <http://www.vcn.bc.ca/~philip/mm/ModuleManager.html>.
It now has a Table of Contents so you can get an overview of the facilities. Run the test applications or 'ModMan' osax and then look at /Users/Shared/info.library.module.0.5.4.mlix in a text editor to see what I mean for the file format.
> * implementing custom handlers in the script.
> * implementing custom properties in the script.
I think it's still not clear:
• ModuleManager manages the property list.
• User specifies which scripts to load by specifying some scripts in the property list -- not by file paths or aliases.
• LibraryLoader manages the loading of scripts by using that specification instead of looking through folders on disk.
Result:
• Easier for users.
• Easier for library loaders.
• Makes other possibilities like I have been talking about with Tommy Bollman and Takaaki Naganoya become real.
> I think these must be optional. Any kind of AppleScript products (.scpt, .scptd, .applescript, applets and droplets) should be able to be treaded as modules without modifications.
> Also rules for your format should be minimum.
Yes, that's what I have been saying and trying to design.
> Following your format must give clear benefits.
> In the case of ModuleLoader, there are two optional requirements.
> * Describe dependencies in the properties by "module" command.
Look in the new beta to see dependency chains available.
> * implement "module loaded by" handler for initialization when the module is loaded.
I'm not clear on this statement.
> But these are optional. And there are clear purpose and benefits.
> You are suggesting kind description and list of a script's handlers and properties as a part of module's format.
Optional, but very handy for users to search many scripts to see what is available.
> But benefits of these information is unclear because tools using these information is not mentioned.
My goal is to make all information available as text -- either XML, HTML, CFStringRef, NSString, or AEDesc (typeUTF8Text or typeUnicodeText).
> Also I feel no requirement of unique identifier you suggested to introduce. I can understand the motivation of introducing unique identifier, but file path is enough. File paths are not perfect identifier but it work well in almost cases.
ModuleManager uses URL strings as "paths". Look in the latest ModuleManager in the test code near the end of MMTestFuncs.c.
if( eref == NULL ) {
/* Put some folders with files in ~/Library/Scripts/Modules.x.x.x/ and observe the document entries. */
eref = MMLibraryRegisterSubfolders( theAllocator, kMMUserLibraryID );
}
kMMUserLibraryID is predefined and alway available.
> After finding cases file paths cause serious problem, we should consider to introduce unique identifier. At this time, ModuleLoader shows unique identifier is not required.
> It's difficult to define only file format without tools using these information.
Yes!
That's why a discussion is good and your comments are appreciated.
I will be starting on the osax example later this week. I hope to show you how easy it is to use the shared property list.
Philip Aker
echo email@hidden@nl | tr a-z@. p-za-o.@
Democracy: Two wolves and a sheep voting on lunch.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden