Difference between revisions of "Talk:Library Categorization"
 
(16 intermediate revisions by 6 users not shown)
Line 55: Line 55:
 
----
 
----
  
−
Instead of '''Language Interfaces''' how about '''Interop'''?
+
Instead of how about '''Interop'''?
  
 
--[[User:Paulb|paulb]] 23:29, 18 August 2009 (UTC)
 
--[[User:Paulb|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"
 
Given the importance of the internet today, it sounds weird to have  EiffelNet under "Utils"
 
Let's add a "Network" category ...  
 
Let's add a "Network" category ...  
 
Then, we could add twitter, jabber, eventually Eiffel Web?
 
Then, we could add twitter, jabber, eventually Eiffel Web?
 +
 
--[[User:Jfiat|Jocelyn]] 05:59, 19 August 2009 (UTC)
 
--[[User:Jfiat|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.
 +
 +
--[[User:Jfiat|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.).
 +
 +
--[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 06:59, 19 August 2009 (UTC)
 +
 +
----
 +
--[[User:Ericb|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)''
 +
--[[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)
 +
----
 +
 +
I would suggest to put the "examples" under the library itself.
 +
 +
This way, a library is a self contained  source+examples and why not +doc+tests
 +
I guess it would ease the discovering of the lib, the path in the ecf for the example, will be relative, so that if later we change the lib categorization this won't be hell to update all ecf.
 +
 +
--[[User:Jfiat|Jocelyn]] 06:04, 21 August 2009 (UTC)
 +
 +
 +
----
 +
 +
--[[User:Ericb|Ericb]] 07:19, 21 August 2009 (UTC): That's what I had planed to do with the Gobo libraries. But using singular names of course! I'm currently considering moving the Gobo repository to git. While doing that, I'm also considering creating a single repository per library and tool. That way people won't have to get the whole XML library if they are only interested in the Decimal library for example. If I do that, of course the libraries will have to be self-contained. Their tests, examples and docs should come along. It would be nice if ISE's and Gobo's (and other's) libraries and tools could follow the same pattern. That way people would be in known ground when they download and use a new library. The directory structure that I have in mind is something like that:
 +
 +
  <library_name>/
 +
      code    (or src, or source)
 +
      doc
 +
      example
 +
      test
 +
----
 +
'''--[[User:Manus|manus]] 17:09, 22 August 2009 (UTC)''': I've taken most of the non-controversial suggestions. Let me know what you think. There are two categories that deserves a better name '''language_interface''' and '''data_structure'''.
 +
----
 +
If '''data_structure''' is replaced by '''concept''', the subnodes could be '''adt''' and '''pattern''' (the latter for the libraries that provide the patterns, e.g. ''event'' could go to this category). Probably, the term '''concept''' is too generic, but otherwise it perfectly matches its subnodes.
 +
 +
The other variants are '''abstraction''', '''structure'''.
 +
 +
For '''language_interface''' the following category names could fit:
 +
* '''bridge''' (unfortunately could be misinterpreted as a pattern name)
 +
* '''invocation'''
 +
* '''platform''' (most suitable from my point of view)
 +
--[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 07:54, 24 August 2009 (UTC)
 +
 +
 +
----
 +
 +
--[[User:Ericb|Ericb]] 21:13, 24 August 2009 (UTC): The reason why I suggested:
 +
 +
  <library_name>/
 +
      code    (or src, or source)
 +
      doc
 +
      example
 +
      test
 +
 +
and not:
 +
 +
  <library_name>/
 +
      library
 +
      doc
 +
      example
 +
      test
 +
 +
is that this directory structure could be used not only for libraries but also for tools.
 +
 +
 +
'''--[[User:Manus|manus]] 15:48, 25 August 2009 (UTC)''': I had thought about that but forgot to add `tool' under my proposal. I think this is better this way as an automatic package distribution will know exactly where to put things. I'm definitely thinking like the Unix layout way.
 +
 +
--[[User:Ericb|Ericb]] 07:54, 26 August 2009 (UTC): My proposal is not about having an automatic package distribution. It's about having everything related to the library (or the tool) located in one single place. When I want to use a library, it is much more practical to see whether there are examples or tests available for this library if they are in directories next to the library's code rather than having to browse through parallel directory hierarchies. I'm sorry, I'm not thinking like the Unix layout way. I'm thinking like I would like it to be as a user.
 +
 +
----
 +
It looks weird to have "runtime" as category. I know it means "at run time", but in our Eiffel world, we are used to talk about the "runtime", as the underlying C library.
 +
What about replacing "runtime" by "execution" ?
 +
This way, we would have
 +
*execution
 +
**memory
 +
**process
 +
**reflection
 +
**concurrency
 +
And I am still unconfortable with having "argument parser" under this "runtime/process" (Or even "execution/process"). It might go under "parser". Even if It is more than just a parser, since it also include the source of argument.
 +
 +
Or we could create an "application" category...
 +
any idea?
 +
 +
--[[User:Jfiat|Jocelyn]] 11:26, 27 October 2009 (UTC)
 +
 +
----
 +
I have to say, I hate the word "execution". We have a habit of using alternative names for things so people coming to Eiffel have no idea where to find things. I would stick with runtime for somethings and add another category.
 +
 +
*runtime
 +
**concurrency
 +
**memory
 +
**reflection
 +
 +
*application
 +
**argument_parser
 +
 +
I don't know where the ''process'' library really belongs. I think we need an '''application''' category for application frameworks. I would be fine with putting ''argument_parser'' under '''parser''' but it might not be found.
 +
 +
Really we need a tag system instead of a tree, which is something integrated into the heart of the library repository idea.
 +
 +
p.s. I like Eric's idea about segregating aspects of a library; source, documentation, examples, and tests. It would be useful to have a dedicated layout for tools and just consistency in general.
 +
--[[User:Paulb|paulb]] 19:16, 27 October 2009 (UTC)

Latest revision as of 10:16, 27 October 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)

I would suggest to put the "examples" under the library itself.

This way, a library is a self contained source+examples and why not +doc+tests I guess it would ease the discovering of the lib, the path in the ecf for the example, will be relative, so that if later we change the lib categorization this won't be hell to update all ecf.

--Jocelyn 06:04, 21 August 2009 (UTC)


--Ericb 07:19, 21 August 2009 (UTC): That's what I had planed to do with the Gobo libraries. But using singular names of course! I'm currently considering moving the Gobo repository to git. While doing that, I'm also considering creating a single repository per library and tool. That way people won't have to get the whole XML library if they are only interested in the Decimal library for example. If I do that, of course the libraries will have to be self-contained. Their tests, examples and docs should come along. It would be nice if ISE's and Gobo's (and other's) libraries and tools could follow the same pattern. That way people would be in known ground when they download and use a new library. The directory structure that I have in mind is something like that: 

 <library_name>/
     code     (or src, or source)
     doc
     example
     test

--manus 17:09, 22 August 2009 (UTC): I've taken most of the non-controversial suggestions. Let me know what you think. There are two categories that deserves a better name language_interface and data_structure.

If data_structure is replaced by concept, the subnodes could be adt and pattern (the latter for the libraries that provide the patterns, e.g. event could go to this category). Probably, the term concept is too generic, but otherwise it perfectly matches its subnodes.

The other variants are abstraction, structure.

For language_interface the following category names could fit:

  • bridge (unfortunately could be misinterpreted as a pattern name)
  • invocation
  • platform (most suitable from my point of view)

--Alexander Kogtenkov 07:54, 24 August 2009 (UTC)


--Ericb 21:13, 24 August 2009 (UTC): The reason why I suggested: 

 <library_name>/
     code     (or src, or source)
     doc
     example
     test

and not: 

 <library_name>/
     library
     doc
     example
     test

is that this directory structure could be used not only for libraries but also for tools.


--manus 15:48, 25 August 2009 (UTC): I had thought about that but forgot to add `tool' under my proposal. I think this is better this way as an automatic package distribution will know exactly where to put things. I'm definitely thinking like the Unix layout way.

--Ericb 07:54, 26 August 2009 (UTC): My proposal is not about having an automatic package distribution. It's about having everything related to the library (or the tool) located in one single place. When I want to use a library, it is much more practical to see whether there are examples or tests available for this library if they are in directories next to the library's code rather than having to browse through parallel directory hierarchies. I'm sorry, I'm not thinking like the Unix layout way. I'm thinking like I would like it to be as a user.

It looks weird to have "runtime" as category. I know it means "at run time", but in our Eiffel world, we are used to talk about the "runtime", as the underlying C library. What about replacing "runtime" by "execution" ? This way, we would have

  • execution
    • memory
    • process
    • reflection
    • concurrency

And I am still unconfortable with having "argument parser" under this "runtime/process" (Or even "execution/process"). It might go under "parser". Even if It is more than just a parser, since it also include the source of argument.

Or we could create an "application" category... any idea?

--Jocelyn 11:26, 27 October 2009 (UTC)

I have to say, I hate the word "execution". We have a habit of using alternative names for things so people coming to Eiffel have no idea where to find things. I would stick with runtime for somethings and add another category.

  • runtime
    • concurrency
    • memory
    • reflection
  • application
    • argument_parser

I don't know where the process library really belongs. I think we need an application category for application frameworks. I would be fine with putting argument_parser under parser but it might not be found.

Really we need a tag system instead of a tree, which is something integrated into the heart of the library repository idea.

p.s. I like Eric's idea about segregating aspects of a library; source, documentation, examples, and tests. It would be useful to have a dedicated layout for tools and just consistency in general. --paulb 19:16, 27 October 2009 (UTC)

Retrieved from "https://dev.eiffel.com/index.php?title=Talk:Library_Categorization&oldid=13511"