my very old/crusty fogot-to-post thoughts on module naming suggestions

nomen.txt

HTTP::*
Hostfile::*
IMAP::*
IPChains::*
IP::*
IPDevice::*
IRC::*
Cisco::*
JUNOS::*
Jabber::*
Nagios::*
Net::...
  Crypt::*
  EasyTCP
  LogFile   --> maint
  RabbitMQ  --> EMS
  ACL       --> oper
  ADNS
  AIM       --> Chat
  AIML      --> Chat
  AIMTOC    --> Chat
  AMQP      --> EMS
  AOLIM     --> Chat
  APE
  API-Gett  --> Cloud::Storage
  API-RPX   --> Auth
  APNS      --> EMS
  APP       --> Auth
  ARP       ::
  ASN       --> ???
  Abuse-Utils --> Net::Admin::Abuse
  Address-Ethernet --> ???
  Address-IP-Local --> IP
  Address-IPv4-Local --> IP
  Akamai    --> Cloud::Storage
  Amazon::* --> non-cloud stuff goes in Provider
                cloud stuff goes in Cloud
                Route53 stuff goes in Provider::DNS
  Analysis  --> PCAP
  AozoraBunko --> Provider
  AppNotifications
  Appliance::* --> admin
  Arping --> testing
  Artera --> provider
  Async --> implemented with individual protocols
  Autoconfig --> admin
  Axingen --> auth and directory
  Azure --> Cloud
  BEEP --> communitcations framework
  BGP --> route
  Backpack --> Provider/Cloud
  Backtype --> Social
  Bamboo --> devel/make/build
  Bind --> DNS
  BitTorrent --> P2P
  Blacklist --> integrated into core address list work
  Blogger --> Providers/Social
  Bluetooth --> ::
  BobrDobr --> Provider
  Bonjour --> DNS/Discovery
  Bot-IRC --> IRC
  BrainTree --> Providers/commerce
  BullFinch --> ???
  CDDBScan --> Audio CD related stuff
  CDP      --> Discovery
  CIDR     --> folded into addressing/routing work
  CLI      --> ::
  COLOURLovers --> Provider
  CSTA     --> oper / voice
  CUPS     --> Fabrication and replication
  OpenCalais --> Provider
  Camera-Edimax-IC1500 --> Video
  CampaignMonitor --> Provider
  CanopyBAM --> admin/vendor
  CascadeCopy -->
  Cassandra --> DB
  Chat --> Chat
  Chaton --> Chat
  Net::Cisco --> OAMP
  Citadel --> email/chat/productivity
  Clickatell --> Chat
  ClientServer --> Daemon utils
  CloudStack --> Cloud
  Net::Comcast::Customer --> OAMP
  Net::Connection::Simple --> folded into protocols
  Net::Connection::Sniffer --> OAMP
  Net::Country --> IPv4
  Net::Curl --> spider
  Net::CyanChat --> chat
  Net::DAAP::DMAP --> streaming servers
  Net::Dav
  Net::DBUS
  Net::DCC --> Chat
  Net::DMAP --> photo/fileharing/media servers
  Net::DNAT --> folded into protocols
  Net::DPAP --> photo/fileharing/media servers
  Net::DRI --> DNS (merges the SP stuff)


TFNPAHHNP6M

The Wiki Page from which a "Totally Friendly and Not at all Passive
Aggressive Helpful Hints for Naming your Perl 6 Module" document might
possibly someday emerge, maybe even with a better title than that.

Feel free to mutilate this page, it is intended as a forum.

This page was initialized as one network engineer's personal opinion
on how to organize Perl 6 modules just a little bit better than CPAN did,
so at first it addressed a network-related subset of modules.

Depending on how many people have bothered to edit it, by the time
you read it, this page may actually represent more than just this one
opinion (you can check the wiki edit history to determine whose.)

Some food for thought:

All-caps top level namespaces are "semi-reserved" per the Perl6 spec,
with existing CPAN namespaces grandfathered.  That said, if you
really think something deserves to be all-caps, say so.  Who knows,
it may end up on some sort of official-looking list if enough people
agree.

Namespaces are actually pretty darn big, so it does not take
much of a reason to justify a root level namespace, and to justify
tucking things away in a subnamespace you should be able to identify
a goodly number of things that you could tuck in there, not just two
or three, but not so many that it becomes a submess of totally
unrelated modules.  It helps if the things tucked in a directory could
usefully share mixins.

We do want to end up with a module namespace heirarchy that is
well Huffman optimized like Perl6 is trying to be.  So, modules that
are extremely popular should not end up jammed in depth-4 subspaces
and modules that are rather obscure should not clutter up well trafficked
areas.  Even if a module really does belong in a classification, it
might be bumped up towards the root namespace if lots of people will
need it.  We'll call this the "household word" test, for some value of
"household" that only includes people likely to try to read or write
Perl6 code.

Just because a particular thing is "the" thing people mean when they
say "Foo" does not mean other similar things cannot share its namespace.
Also, when considering a namespace, try reversing the words in the
module, and see if that makes sense and would provide a place to
put similar modules.  For example, we could have a module named
Mozilla::Bookmarks, or we could have a module named Bookmarks::Mozilla
and if we did the latter, we would now have a tidy place to put
Bookmarks::Opera and Browser::Chromium, and more importantly,
Bookmarks.pm6 which could have mixins that all three use.

Now a word from the ministry of anal-retentiveness:

Some fields are used in many of the entries below; don't feel obliged
to do the same (feel free to ramble) but you might find it helpful
exercise to do so, so here is what is in each field.

Suggest possible names for a namespace in the "NAMES:" field.

The "WHATFOR:" field describes the categorization criteria for the
namespace.

Next, pretend for the sake of argument that perl5 modules on CPAN were all
going to be rewritten in Perl6 without any merging or splitting.  In
the "MOVETHERE" field, name examples of modules that would end up in
this namespace.  You can also name other things that don't have a P5
module, but probably should.

Once the "WHATFOR:" field is worked out, read it over again and
think of things that someone else who read that might try to
put in the namespace, but which really should go somewhere else.
Describe those in a "WHATNOTFOR:" section and maybe offer a
suggestion as to where those things should go.

DISSENT: If you don't like an entry, politely say why here.

VOTES: initialize to 1 when creating a new entry.  If you like an
entry that's already there, feel free to increment by one.  Honor
system.

You are of course also encouraged to enhance sections that are already there.

======
NAMES: *::SP::
WHATFOR: a subspace called "SP" may be found under various primary
namespaces.  "SP" stands for "Service provider" but may mnemonically be
thought of as standing for "Specialized".  These subdirectories are where
we put modules that interface with the various ad-hoc APIs provided by
providers running services.  The loose criteria for designating a module
as SP as opposed to placing it in the main subdirectory are: 1) the
service relies on external systems provided by a service provider and has
very limited use if those external systems are disabled by the service
provider and/or 2) the APIs are not standardized by a standards body and
may change at the whim of the service provider and/or 3) only an
exclusive set of customers of the service provider would want to use
these modules.  What that boils down to is keeping modules that are
either likely to become orphaned/obselete or which are of interest
to a limited few out from underfoot.
WHATNOTFOR: While Perl6 is founded on OpenSource principles and the
community strongly supports them, the SP subspaces are not for OpenSource
purity tests of an API's origins.  A vendor that has acheived respectable
market penetration, isn't likely to disappear in a puddle of red ink,
and has not been capricious/irresponsible about changing or deprecating
APIs might be bumped up towards the root.
MOVEHERE: as an example, Net::BobrDobr might be Bookmarks::SP::BobrDobr
DISSENT:
VOTES: 1

======
NAMES: Net::
WHATFOR: Core of network packet processing code.  Mostly provides base classes
and mixins that protocol codes (residing in other namespaces) would use,
covering areas such as address formats, packet/frame/cell formats, SAR, OS
interfacing that did not fit in the IO:: namespace, autoloading maps from
proto/service IDs to other modules, enumeration of network-related constants.
WHATNOTFOR: Individual protocols and services, many of which fall under
the "household word" rule.  90% of the stuff that is in the CPAN Net::
directory for perl5.
MOVETHERE: common code usable by Net::Frame::*, Net::Address::*
COMMENTS: A Net::OAMP subspace would gather things that are only of interest
to professional network administrators (e.g. nmap), and OS-specific directories
(e.g. Net::Linux) would handle OS interfaces for things like host
firewalls, but only enough to provide code for modules from other namespaces.
Minus Net::OAMP this directory would be a candidate for distribution
with the Perl6 environment.
namespaces to use.
DISSENT:
VOTES: 1

======
NAMES: P2P::
WHATFOR: "Peer-to-Peer" network protocols (as commonly understood)
WHATNOTFOR: Self-assembling mesh networks unrelated to the mundane, content-
sharing connotation of the term "Peer-to-Peer", e.g. Chat applications,
Cloud computing related applications, ZigBee, Skype
MOVETHERE: P2P::pDonkey Net::BitTorrent Net::Gnutella flavor-of-the-week
           flavors-of-weeks-past
COMMENTS: P2P is a grandfathered CPAN all-caps name.  Might need an SP
subdirectory.
DISSENT:
VOTES: 1

========
NAMES: IPv4::
What for: Layer 3 IPv4 basecode and constants, support code for managing
IPv4 on local system.
What not for: TCP/UDP/ICMP or even ESP/AH/GRE.  This is specifically IPv4 not
services/protocols (as those can just as easily run over IPv6 or in some
cases another L3 protocol entirely)
MOVETHERE:  Net::Country Net::Address::IPv4::Local
COMMENTS:
DISSENT:
VOTES: 1

========
NAMES: IPv6::
What for: Layer 3 IPv6 basecode and constants
What not for: NDP
MOVETHERE:
COMMENTS:
DISSENT:
VOTES: 1

========
NAMES: Ndp::
What for: Protocols whose primary purpose is to help a host autoconfigure
on a network, through address acquisition, service discovery, or service
announcement/request usually via network broadcast or multicast facilities.
If useful, some mixins for use by the other modules in this namespace
also go here.
What not for: Access authentication protocols like EAPOL, those go
in Auth::.  Internet name system facilities like DNS and MSDNS, those
go in DNS::
MOVETHERE:  Net::ARP Net::CDP Net::Bonjour Net::UPnP LLDP IPv6 mDNS/Avahi
COMMENTS: IPv6 breaks from ARP and calls the comparative feature "NDP"
for "Network Discovery Protocol".  We put this in here as NDP::IPv6
and we also put other discovery protocols in here.  Whether DHCP should
go in here or have its own top level entry is a tougher question, since
it is a "household word".  Also, WoL would be a stretch to call an NDP,
but a case might be made to put it here.
DISSENT:
VOTES: 1

=====
NAMES: DNS::
WHATFOR: Name resolving systems especially core DNS modules, but also
MS-DNS facilities and other things one mind find in, say nsswitch
MOVETHERE: Net::Bind::* Net::DNS::* Net::ADNS DNS::Zone* DNS::BL Net::DDDS Net::DRI
WHATNOTFOR: Web APIs for Registrar services like OpenSRS or DNS
Providers like DynDNS.  Those go in DNS::SP::, except for abstration
attempts like Net::DRI.  TinyURL.
COMMENTS: DNS:: is grandfathered all-caps from CPAN.  DNS itself gets
dibs on "use DNS"
DISSENT:
VOTES: 1

=====
NAMES: Chat::
WHATFOR: Chat and instant messaging systems, along with shared mixins for same.
MOVETHERE: Net::Jabber Chatbot IRC Net::DCC Net::Async::IRC Net::AOLIM
Net::SMS::* Net::Social::Service::* Net::Chaton Net::Clickatell Net::CyanChat
WHATNOTFOR: e-mail.  The chat component and file transfer component of voice
systems and/or desktop sharing suites may be here (or may just source the
mixins) but the rest of the suite should not be put in here.
COMMENTS:
DISSENT:
VOTES: 1

=====
NAMES: Spider:: Crawl:: WebSpider:: WebCrawl::
WHATFOR: Web spidering/crawling utilities and sub-components
MOVETHERE: Net::ChooseFName Net::Curl
WHATNOTFOR:
COMMENTS: Spidering might be liberally interperated to include operations with browser "read offline" features.
DISSENT:
VOTES: 1

=====
NAMES: IO::
WHATFOR: Low level OS IO -- sockets, pipes, IPC, MMAP, etc.
MOVETHERE: See Synopsis 16
WHATNOTFOR: Ask on IRC
COMMENTS: This namespace contains modules that are part of the formal Perl6
standard and will likely ship with base Perl6 distributions.  If a module
is not about interfacing to core IO facilities, people will probably not
like to see it placed in this namespace.

======
NAMES: WebAPI:: WebService::
WHATFOR: Protocols used for programmatic communication in a "Web Services"
oriented framework, that is to say, programmatically doing things that were
originally (or just also) designed to be done interactively by a user
on a web browser or which facilitate embedding content between websites.
More cynically put: "retrofitted, streamlined, approved and facilitated...
screen-scraping."
WHATNOTFOR: Web APIs for exclusive use with individual service providers
go in the WebAPI::SP:: subspace.  Protocols more oriented towards distributed
computing and cloud computing go under Cloud::  Enterprise Messaging Systems,
Message Oriented Middleware,  Directory Access Protocols, and ORBs.
Interfaces for DNS registrars and providers go under DNS::SP.
COMMENT: The Ems:: Orb:: WebAPI:: and Cloud:: subspaces are more
trend-oriented distinctions than functional.  It is tempting to try to
categorize based on RESTful-ness but that is likely to be less useful
to users.  Often some of these services can be for relatively specialized
purposes and might be better placed with other modules related to that --
this namespace is for systems which aim to be generic.
DISSENT:
VOTES: 1

=====
NAMES: OS::
WHATFOR: Core OS interfaces
MOVETHERE: See Synopsis 16
WHATNOTFOR: Ask on IRC
COMMENTS: This namespace contains modules that are part of the formal Perl6
standard and will likely ship with base Perl6 distributions.  If a module
is not about interfacing to core OS facilities without which Perl6 would
be relatively crippled, people will probably not like to see it placed in
this namespace.

=====
NAMES: Test::
WHATFOR: Perl6 build environment test suite
MOVETHERE: See Synopsis 24
WHATNOTFOR: Ask on IRC
COMMENTS: This namespace contains modules that are part of the formal Perl6
standard and will likely ship with base Perl6 source distributions.  If a
module is not about testing Perl6 implementations or modules people will
probably not like to see it placed in this namespace.

=====
NAMES: POD6::
WHATFOR: Perl6 Plain Old Documentation
MOVETHERE: See Synopsis 26
WHATNOTFOR: Ask on IRC
COMMENTS: This namespace contains modules that are part of the formal Perl6
standard and will likely ship with base Perl6 source distributions.  Seriously,
what else would you possibly want to put in here?