Difference between revisions of "Talk:Library Categorization"

Line 112: Line 112:
 
* security ''(fictional)''
 
* security ''(fictional)''
 
--[[User:Ted|Ted]] 03:27, 20 August 2009 (UTC)
 
--[[User:Ted|Ted]] 03:27, 20 August 2009 (UTC)
 +
----
 +
 +
One item that has not been discussed is what happens with the example project corresponding to libraries. The proposed library structure allows for contrib or unsupported libraries which may have examples to. I suggest we model the examples to match the library structure hierarchy.
 +
 +
--[[User:Paulb|paulb]] 23:31, 20 August 2009 (UTC)
 
----
 
----

Revision as of 15:31, 20 August 2009

Instead of gui_design, gui_graph, ... I would prefer

  • gui
    • design
    • graph
    • ..

argument_parser would be better as

  • parse
    • argument

About Gobo, it could be exploded into kernel, structure, time, parse, lexical, xml, ... But we can not do that, so what about adding a category "Package", or "Framework"

--Jocelyn 08:12, 13 August 2009 (UTC)


I would suggest the following 2-layer structure (if there is a new name, the old one is written in parentheses, in particular, something_extension is not very meaningful):

  • base: Kernel library classes, data structure, reflection, I/O
  • concurrency
    • process: Facility to start and follow processes
    • thread: Threading in Eiffel
    • cgi (web): CGI facility for Eiffel
  • external: interface to the external software
    •  ? (api_wrapper): Make it easy to call C routines from dynamically loaded shared libraries
    • com: COM technology
    • java (Eiffel2Java): Calling Java from Eiffel
  • gobo: Gobo
  • gui
    • docking: Facility to have a customizable UI.
    • event: Low level mechanism to receive a UI event when a file/pipe has something new.
    • graph: Representation of graph in UI (See diagram tool in Eiffel Studio).
    • vision2: Platform independent UI toolkit
    •  ? (vision2_extension): Extension to Vision2
    • wel: UI toolkit for Windows
  • storage
    • memory (memory_analyzer): Memory analysis
    • preferences: Facility to store user preferences
    • store: Relational database access
  • text
    • argument (argument_parser): Parsing the command line arguments of a program
    • diff: Diff and patch facilities
    • encoding: Transforming text in one encoding to another encoding
    • i18n: Internationalization library:
    • lex: lexical analysis
    • parse: Parsing:
    • uuid: UUID generation facility
  • util
    •  ? (gobo_extension): ISE gobo extensions
    • net: Networking library
    • testing: Testing facility
    • time: Time facility

--Alexander Kogtenkov 15:52, 18 August 2009 (UTC)


Instead of how about Interop?

--paulb 23:29, 18 August 2009 (UTC)


To comment Alexander's message: Given the importance of the internet today, it sounds weird to have EiffelNet under "Utils" Let's add a "Network" category ... Then, we could add twitter, jabber, eventually Eiffel Web?

--Jocelyn 05:59, 19 August 2009 (UTC)


"Preferences" under UI/interface looks weird to me. If I were looking for preferences lib, I would search under "data" or "database" or "storage", but not in "ui". However, the pref lib also has Graphical components. In final, ... we should allow more than one category for a lib.

--Jocelyn 06:24, 19 August 2009 (UTC)


Language Interfaces looks too long for me as well. In fact here we are talking more about interfacing to the external software, not to the particular language, as, for example, COM is a technology and not a specific language. Interop is associated for me with .NET... Just a few other possibilities:

  • software
  • call

Also, api_loader sounds too generic. Shall it be library_loader or even library_accessor instead?

Would it make sense to merge data and data_structures into data with subnodes database and adt? If not, it might make sense to rename data into persistency or something like that. Also, does event library belong to ADT? According to the description it's more about GUI and IO, so it could be moved to ui section.

There is some inconsistency in naming as both singular and plural nouns are used. Probably it's better to stick to the same naming convention and use (as in Eiffel) only singular forms (utility instead of utilities, etc.).

--Alexander Kogtenkov 06:59, 19 August 2009 (UTC)


--Ericb 07:51, 19 August 2009 (UTC): For the event library, what about the category pattern?

About singular vs. plural, I'm all for singular names as well. I noticed in the some libraries that there are folders example. That's good. But in some others we can find tests. In order to be consistent, everything should be singular.


vision2_extension should be put in vision2, only that vision2_extension.ecf can be put beside vision2.ecf. To find argument_parser, I would first go to text rather than process (agree with Alexander).

For the categorization, in general, we should make it as extensible as possible for not only existing libraries but also for coming ones. For example, Video/Audio, Security/Encryption, 3D Graphics and so on that are missing ones. Some of them will be put in new folders, others will be put into existing folders.

For this reason, I think ui/gui is not a good name for general graphics stuff, graphics is better instead. We would suggest something like this:

  • graphics
    • drawing
      • graph: Representation of graph in UI (See diagram tool in EiffelStudio)
      • OpenGL (fictional)
      • DirectX (fictional)
    • ui
      • docking: Facility to have a customizable UI
      • vision2: Platform independent UI toolkit
      • vision2_extension: Extension to Vision2
      • wel: UI toolkit for Windows
  • media (fictional)
    • video
    • audio
  • security (fictional)

--Ted 03:27, 20 August 2009 (UTC)


One item that has not been discussed is what happens with the example project corresponding to libraries. The proposed library structure allows for contrib or unsupported libraries which may have examples to. I suggest we model the examples to match the library structure hierarchy.

--paulb 23:31, 20 August 2009 (UTC)