[erlang-questions] A Generic API for controlling software components

[Frank Mueller]

Hi Joe,

your idea sounds really good to me, even if I would like some changes.

>     Draft 1 - 25 Nov 2009
>
>     Rule1: All components are unpacked into the same top-level
>            directory (default $HOME/eComponent) and have the extension
>            .ec (Erlang component)
>
>            Example: Imagine I have installed mochiweb ejabberd and couchDB
> 	   then after installation I should see the following:
>
> 	   $pwd
>            /home/joe/eComponents
>            $ls
>            mochiweb.ec ejabberd.ec couchDB.ec

It's OK to have a default value for the directory, but I would like to have a defined variable
named $ECOMPONENT_HOME so that I can easily change it.

Rule 2 and 3 full ack.

>     Rule4: All components C must have a file called
>
>            $HOME/eComponents/C.ec/Preferences.pl
>
> 	   The extension .pl means the file contains a property
>            list. Here is an example:
>
>            {codePath, "/bin"}.
>            {expiryDate, {2009,12,24}}.
> 	   {icon, "/images/myIcon.png"}
> 	   {version,1}
>            {myKey1, ...}
>
>            The keys codePath, version, and expiryDate are obligatory
>
>            Why do we need code path? - so that Erlang can find
>            a module called C.erl
>
>            Expiry date has a "time to live for the component"
>            Version is used for local configuration data (see later)
>            Version numbers should start at one and be increased by one
>            for each new release.

Here I would like to have a consistent naming style. Until today most parts of Erlang don't use
camel case. I like it in Smalltalk, and I like the consistency inside Scheme, and until today I
like the consistency in Erlang. It's not like Python, where you can see which libs are from the
Smalltalk or Java side, from the .NET side or the C side. Awful. So it should be called
preferences.pl with code_path, expiry_date, and so on. Additionally I would like nested
preferences. My Tideland CEL celcfg module handles this well.

>     Rule5: Local configuration data
>
>            Local configuration data must not be stored under the
>            eComponents directory - (you can't remember we said the
>            component is in a read-only disk area - see rule2)
>
>            Local data for the component C must be stored
>            in the directory
>
>            $HOME/eLibrary/ComponentName/Vsn
>
> 	   Thus local preferences for ejabberd version 1
> 	   would be stored in the file
>
> 	   $HOME/eLibrary/ejabberd/1/Preferences.pl

Ack, but see comments above about env variable and naming.

Rule 6 and 7 again ack.

Thx for this idea, Joe. I would like to make my Tideland EAS conforming to such a standard.

mue

-- 
**
** Frank Mueller / Oldenburg / Germany
**