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

[Joe Armstrong]

On Wed, Nov 25, 2009 at 11:55 AM, Frank Mueller <frank@REDACTED> wrote:
> 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.

Yes

>
> 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.

I use names_like_this for function and module names but namesLikeThis
for atoms in code


>>     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.

Great - I'm going to write a generic manager to support this. But I'd
like some discussion
in the list first.

>
> mue
>
> --
> **
> ** Frank Mueller / Oldenburg / Germany
> **
>
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>