Win-Labor Naming

From GEANT2-JRA1 Wiki

Brainstorm - perfSONAR-xxx, xxx-perfSONAR-xxx or perfSONAR-xxx

  • perfSONAR-WIN
  • perfSONAR-Labor
  • perfSONAR-Simar (I particularily like this one ;)
  • perfSONAR-SleepyCat
  • perfSONAR-BlueStone
  • perfSONAR-Lite

Contents

[edit]

Win-Labor products Naming

[edit]

perfSONAR-MDM packages and product naming

[edit]

DFN-Labor suggestion:

Branding is necessary for perfSONAR related work in various different aspects. It can loosely be described following a hierarchical approach.

Disclaimer: Our suggestions are based on technical issues only. It neither takes political issues into account, nor was it written to raise new political issues. It presents the conclusions drawn by looking at different Open Source project that face similar problems.

The name we would like to use for our Perl based services is Perl perfSONAR. Yes, that's indeed very fanciful ;)

Please note that this is (as everything below) just a suggestions. Perhaps we can find an even better name...


[edit]

The perfSONAR universe

perfSONAR is the "overall name" of what we are doing, as we describe it on perfsonar.net. It is used for everything directly related to the perfSONAR standards "universe" (mainly the "perfSONAR protocol" and the "perfSONAR architecture").

Normally we all should see ourselves as being part of the perfSONAR community.

  • Comparison to other Open Source project:
    • The Apache community
    • The KDE community


[edit]

Release Bundles

Very often perfSONAR based software is used for a special purpose in a large network installation, that may even be a virtual network. Good examples are MDM, LHC, and EGEE projects. For this purpose it is very helpful to bundle the required software in a Release Bundle that has its own release management to ensure that the parts work together as expected.

Keep in mind: A Release Bundle name is in most of our cases some sort of "product name" for the targeted customer!

  • Examples:
    • perfSONAR MDM (or MDM perfSONAR?)
    • perfSONAR LHC
    • perfSONAR EGEE
  • Comparison to other Open Source project:
    • Apache is afaik not releasing any bundles.
    • The KDE release 4.0.3


[edit]

Software Packages

This is most likely the main controversial topic! We really see a problem when talking about "parts" of the perfSONAR universe. These problems arise always when talking to users or developers about these "parts". Let me give some real life examples:

1. Recently in a talk with Andreas Hanemann (he should be seen as a developer in this context) we found out that he had a totally "unclear" view on WiN-Labor's perfSONAR software. He thought we had implemented different Perl perfSONAR services. But that's wrong! We have implemented a generic Perl perfSONAR service that can handle different requests based on a plug-in architecture. He always heard about BWCTL MP and never about Perl perfSONAR.

2. The request from EGEE that reached us via the DFN can be seen as a "user request". They more or less explicitly stated in their request, that they don't want perfSONAR, because it is too big and based on Java. With "perfSONAR" they obviously meant the Java services of perfSONAR MDM. It took us a lot of time to just clear up the basic facts what perfSONAR actually is. It would have been much easier for us, if we had used simple sentences like the following: 

 We have a software package called "Perl perfSONAR" that already includes
 a BWCTL MP (a perfSONAR Web Service). This is the same BWCTL MP used in the
 perfSONAR-MDM bundle release."

There are also concerns about having the term Perl in a name, because users don't know about programming languages. We disagree here. Two points:

1. All (potential) "users" (like MDM, LHC, EGEE, DFN) so far do not only know about programming languages, they also have requirements directly connected to the used programming languages. For example most of them prefer Perl and not Java. Btw: We disagree here! Most of the pros and cons about Perl and Java they mention are inappropriate or even wrong. But that's a different topic...

2. What if there is really a potential perfSONAR user out there that doesn't know what Perl is? Who cares!! Perl perfSONAR means the same to him/her as DFN perfSONAR, WiN perfSONAR, Hades perfSONAR, Foo perfSONAR, Bar perfSONAR, Blub perfSONAR and so on.

To sum up: These "part names" are very useful for a high-level view on perfSONAR. They point out the different "flavours"/sub projects perfSONAR consists of.

Btw: We don't like the term Software Package, because it conflicts with the term as it is used in package managers. But we had problems finding a better solution. Very often "project" is used, but this is even more misleading in our case... Perhaps we should use sub project.

Now arises the question what is part of a Software Package. For example you can take a look at Java perfSONAR. The term "Java perfSONAR" designates a Software Package including perfSONAR base and all Java services, that are accepted as part of the software package. The normal way used in similar Open Source projects is to start a new service as a separate "software package based on Java perfSONAR". But after it is stable enough and commonly used, it is included into software package Java perfSONAR. As an example you can look at the way Java and Perl include new classes/modules in their "standard distribution".

  • Examples
    • Java perfSONAR (maybe)
    • perfSONAR-PS
    • Perl perfSONAR (maybe)
    • Python perfSONAR (maybe)
  • Comparison to other Open Source project:
    • Apache uses the term project here. Typical projects:
      • HTTP Server
      • Ant
      • Maven
      • Tomcat
      • ...
    • The KDE Community itself consists of different packages:
      • kdeaccessibility
      • kdeadmin
      • kdeartwork
      • kdebase
      • ...
    • But there is also KDE software that is not (yet) included to the standard software packages, but that might be included in future releases and that is normally related directly to specific KDE versions for compatibility reasons:
      • knoda
      • kexis
      • kchmviewer
      • kplayer
      • ...


[edit]

Package Manager Packages

A completely different issue is the "lowest level" of the hierarchy. The hierarchy from above has to be mapped to actual software packages for package managers. Most important here is that it is impossible to find a common way of mapping. Every package manager has it's own rules and the operating system using it is putting even more rules above these package manager rules. E.g. RPM itself is a very flexible system providing quite a lot of degrees of freedom and distributions using RPM often only provide best practice rules. On the other hand Debian, which has its own packaging system, has very strict rules that are also strictly enforced.

[edit]

Granularity

Normally package manager packages are using a far finer granularity than a project normally foresees. This is normally based on technical issues, like package dependencies. E.g. if the Perl services are in the same package as Java services and you need only one of the Perl services, you would have to install Tomcat to fulfil the dependencies, although you actually don't need it.

  • Examples (mainly typical RRM style):
    • perfSONAR-base
    • perfSONAR-java
    • perfSONAR-java-rrd-ma
    • perfSONAR-java-ls
    • perfSONAR-perl
    • perfSONAR-perl-bwctl-mp
    • perfSONAR-perl-hades-ma
    • perfSONAR-PS
    • perfSONAR-PS-pinger-ma
    • perfSONAR-rnp-cl-mp or simply perfSONAR-cl-mp - if they don't want to "belong" to perfSONAR-java
    • perfSONAR-python
  • Comparison to other Open Source project:
    • For HTTP Server project of the Apache Community:
      • httpd
      • httpd-manual
      • mod_ssl
      • ...
    • For KDE package manager packages are very similar to the Software Packages. Especially the source packages. But nevertheless for the real binary packages things are different:
      • kdeaccessibility
      • kdeadmin
      • kdeartwork
      • kdeartwork-kscreensaver
      • kdeartwork-sound
      • kdeartwork-xscreensaver
      • kdebase
      • kdebase-devel
      • kdebase-extra
      • kdebase-kdm
      • ...
[edit]

Bundles

Although bundles are on a very high level in the hierarchy, they need to be taken into account for the names of the packages as well. It has to be possible to distinguish a package belonging to a bundle from the similar packages belonging to a different bundle or that are used without being part of a bundle release.

There are indeed different ways to handle packages that are part of a bundle. It heavily depends on the package manager and/or operating system/distribution.

  • Example 1
    • perfSONAR-MDM-base or just perfSONAR-MDM (if there is the need for a common "base package" at all)
    • perfSONAR-MDM-perl
    • perfSONAR-MDM-perl-bwctl-mp
    • perfSONAR-MDM-perl-hades-ma
    • perfSONAR-MDM-java
    • perfSONAR-MDM-java-rrd-ma
    • perfSONAR-MDM-java-ls
  • EGEE only wants Perl services? Make things easier then:
    • perfSONAR-EGEE
    • perfSONAR-EGEE-BWCTL-MP
Retrieved from "http://wiki.perfsonar.net/jra1-wiki/index.php/Win-Labor_Naming"
Personal tools