>> Although it is interested to have this kind of information about >> what Etoile will be, >> I am more interested in how we can build this kind of environment. > > Well, actually we need both ;-) --> this kind of infos is for the > moment not really > for the users (which users ??) but more as a "what are we supposed to > provide". > In that view I think that page is really interesting, because we need > to know > and agree on what the environment is supposed to do... and things > aren't clear yet :) > >> We need to a more detailed diagram about the Etoile for developers, >> for example, which framework is build on top of which framework. >> The most bottom one is of course GNUstep. >> Then what is the framework just above it ? >> A compress library and a regular expression library come to my mind >> first. >> LuceneKit need both of them, and a workspace build on top of >> LuceneKit (and others). >> >> So my point is that it is very nice to have this document for users. >> We also need a similar document for developers of Etoile. >> It's hard to tell the relationship between components >> from the existed document on Etoile wiki. >> With this kind of diagram, we can also have a progress report >> on each component so that people will can when Etoile will be >> completed. > > Yes, but as I said, this document is also useful for developers, as it > provides a > well defined goal (or, it should :) > When we all agree on the goals, then we can start agreeing on the > technical > means and the rest of the architecture, I think. > > For example, the UI we want is still rather fuzzy for me; and how we > want to actually > do metadata, components or versioning is still not clear. > > I think thoses points are really important to clear before, no ? > > Of course, there's a lot of "low level" > technologies/libraries/frameworks that we > more or less know we need, such as LuceneKit, but it's important to > have an idea > of the "big picture" imho.
Exactly, Nicolas. While I don't doubt we need some kind of Developers Reference for how Etoile will work, we need to clarify the goals and interaction methods of Etoile first, or else every developer will be implementing his version of how he thinks the system will work -- resulting in chaos when everyone comes together to find out that Etoile means something different to each developer. In a bizarre coincidence, I just finished reading the Design of Everyday Things by Donald Norman, and he suggests that user manuals should be written _before_ a project is created, precisely because it does give an overview of how the project should work and focuses on actual interactions and usability. That doesn't mean the manual won't get revised as the project develops, but the two can at least stay in sync and one can serve as a reference for the other through development... and doing it this way means we already have working documentation when we release the project :) J.
