Re: [gobo-eiffel-develop] Hello

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> A few things:
> 
> 1. I think ECLI is also a good candidate (odbc access).

Yes, and there are probably many others as well.
But we have to start somewhere ;-)

> 2. Does anyone know Perforce? (http://www.perforce.com). I like its
>    version control system much more than CVS, its available for free
>    for Open Source projects.
>    However, CVS and SourceForge are already setup and available, but I
>    just wanted to know if more people know and like Perforce.

I never used Perforce. I use CVS at work (I used it in my previous
work as well and when I was at ISE also) and for Gobo locally on my
PC before I moved it to Sourceforge. CVS is not perfect but it has
been good enough for me so far and it has the advantage of being wildly
used I think. And as you said it's already there for us on SourceForge.

> 3. For the guideline: note that eposix also has several layers like a
>    Standard C, POSIX, Single Unix Specification and an abstract layer
>    (common subset of POSIX and  Win32). With single prefixes like PX
>    or so I don't get that far in communication the structure. Perhaps
>    you can give this some thoughts.

Yes, I thought about that two days ago as well. What about
possibly allowing several prefixes for some libraries. It
is actually already the case for the Lexical library with
LX_ and YY_ (for skeleton classes) and for the Parse library
with PR_ and YY_ (again for skeleton classes). And if we
integrate the Unicode cluster into the Kernel library we
would also have KL_ and UC_ for this library. So provided
that these prefixes are well documented (i.e. have a page
listing all the libraries with their prefixes used) so that
we can avoid clashes, I don't think that there is any problem.
So what about SC_, PX_, SU_, etc. for the different layers?
Of course you (and any other developer) are free to choose
the prefixes you want provided that there are not used yet.

> 4. It's great to see UCSTRING become part of the lib.

Agreed.

> 5. The name: I think the Gobo name is quite usefull as it is
>    well-known. But what about a somewhat more catchy name like Unified
>    Gobo? "The Unified Open Source Eiffel Library" is to formal, but
>    Unified Gobo sounds as somewhat more important for this large
>    undertaking.
>    But I'm also just fine with Gobo.

I would say the shorter the better. For example the full
name is actually Gobo Eiffel, but everybody just calls it
Gobo because it's shorter. So I would rather stick to
Gobo as a name, even if the documentation will clearly
state that it's a multi-developer multi-library project.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com