[Cuis] Package structure et al

[H. Hirzel]

Thank you Ken, for the additional explanations.

Yes, labeling the basic directory with the version number (e.g.
Cuis-1.4) and having Cuis (with the image) and all the packages as
subdirectories makes sense according to
    "What is the simplest thing that will work?". (eXtreme Programming question)

Regarding package dependencies. We have

* WebClient depends on Network
* some packages depend on the Pharo 1.4 compatibility package done by German A.

May I ask you to rework (not much) what you have written in the
previous mail, describe how we think development should be done in
terms of directory structure, put it into an *.md file, add it to your
Cuis fork and issue a pull request to Juan?  This will keep the
results of this thread readily accessible to other people who will
join the Cuis effort  :-)

--Hannes

On 1/9/13, KenD <Ken.Dickey at whidbey.com> wrote:
> FYI: I keep siblings in a directory named by the (major) release:
>  ../CUIS-1.4/Cuis
>  ../CUIS-1.4/Cuis-Ia-En
>
> I would prefer this to .gitIgnore as I suspect there will be fewer name
> collisions.
>
> We already have the potential for confusion with package names.
>
> Perhaps someone wants to add code for Interlingua to
> Spanish/French/Italian/.. in the Interlingua package.
>
> If the code is unshared, siblings can be loaded in any order.  If common
> code is used, there will be a composition order.
>
> In the ideal world, one should be able to look at package info [assume a
> package header/manifest & requirements] and do a transitive closure over all
> package requirements to get a proper load order or find a missing
> requirement or code clash [e.g. same class name defined with different
> code].
>
>
> The question I like to ask is "What is the simplest thing that will work?".
> (eXtreme Programming question)
>
>
> In the short term, I favor sibling directories as I think that this will
> confuse me the least.
>
> I would like to move to a package header which gives the
> compatibility.version = major.minor and lists package dependencies: zero or
> more of { packageName compatibility }.. ).
>
> I don't think an implementation is needed until the first package with a
> dependency requirement, but given networking, web servers, and so forth this
> day may not be far off.
>
> As far as I am concerned, Juan is king of the CUIS universe (think Linus
> Torvalds and Linux).  We should not overburden him with demands.
>
> One way to go forward is to have people who propose things do a
> prototype/sample implementation.  This helps avoid too many people proposing
> too many things, gives concrete examples to aid communication, and gives
> people something to try out and improve or discard.  Juan can then either
> ignore, replace, improve, or adapt a suggestion without having to write
> every line of code himself.
>
> Right now we are doing "baby steps" so this is not (yet) a big thing.  But
> success must be carefully managed so CUIS can grow without being smothered.
>
>
> Wow.  This is getting long.  I better stop typing.
>
> So, what is the simplest thing which works?
>
> -KenD
> --------------------
> When I works, I works hard.
> When I rests, I rests easy.
> When I thinks, I goes to sleep.
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>