Naming guidelines for plugins, etc

ServiceStack Plugins
1

I was wondering if you have any naming guidelines we could/should follow for naming plugins (that may or may not get published to Nuget, or that we develop for our clients), either pure individual OSS contributions, and/or company sponsored plugins as well.
Some products/companies like Wordpress, Atlassian seem to have formal guidelines that they try to enforce for example, and while there really is no marketplace for ServiceStack plugins aside from Nuget, perhaps you have recommendations (https://make.wordpress.org/plugins/2015/10/05/guidelines-for-plugins-that-include-company-andor-product-names-in-the-plugin-name/, https://developer.atlassian.com/market/branding-your-add-on, http://docs.splunk.com/Documentation/Splunkbase/splunkbase/Splunkbase/Namingguidelines).

For example, if I have a plugin that provides a hypothetical XYZ service, or integrates with an XYZ product, that I might one day want to put on Nuget, any recommendations?

  • Title: XYZ Service for ServiceStack, XYZ Service powered by ServiceStack
  • Nuget Package Names:
    • ServiceStack.Contrib.XYZ
    • ServiceStack.Contrib.XYZFeature
    • MyCompany.ServiceStackContrib.XYZ
    • MyCompany.Ssc.XYZ (i.e.: no recommendation, just don’t use ServiceStack in the name)

There are pluses or minuses for each. ServiceStack.Contrib.* is convenient when coding and for intellisense and using extension methods, etc…, but may also suggest it’s “blessed” by the ServiceStack company which it may or may not be, and you may or may not want. Just asking for your thoughts, 'cause having to refactor later would be a pain and ideally unnecessary, thanks!

2

Firstly it’s completely fine to use ServiceStack after your company name in which case you control the namespace and can name the package anything you want, e.g:

MyCompany.ServiceStack.Name*

I wouldn’t use Contrib* anywhere, it’s already implied when you start with your company prefix and the added verbosity makes the package seem unnecessarily complex.

It’s also ok to use ServiceStack prefix but it’s a good idea to check with us first so we can agree on name which should normally follow the format:

ServiceStack.{Category}.Name

E.g. if it’s an Auth Provider or Auth repo it should start with:

ServiceStack.Authentication.*

If it’s a Caching or Logging Provider, starts with:

ServiceStack.Caching.*
ServiceStack.Logging.*

etc. If you let us know the type of plugin you want to create we can come up of a good category name if one doesn’t exist already.

There’s no market place for plugins yet but we’ll add them under the relevant docs so they can be found. We also have on our task list to create an open and editable community website to showcase community content and plugins which we’re adding under the https://github.com/ServiceStackCommunity repo, which you’re also welcome to host your ServiceStack related repo’s under there if you’d like. We’re slowly getting all the pieces in place to create a bespoke Github-based CMS so it will be easy for everyone to contribute to with PR’s but we still need to create the actual website which we’ll get to eventually as we find the time.

3

Ok, great … I think for now, I’ll go with the MyCompany.ServiceStack.Name* convention then, which will work fine for my clients and audience for now, and when I get around to publishing, I’ll notify you guys so you can take a look if you want. If for some reason, there’s broader appeal, then transitioning to a ServiceStack.* namespace/package could be considered with your guidance/recommendations/changes, as “in my mind”, I tend to think of packages starting with ServiceStack.* as packages you have vetted to a fair degree to meet core philosophies at minimum, conventions, etc …

A Github-based CMS and marketplace sounds great btw! :smile:

1 Like