Request for input: Prototype code, add "options" to pkg_svc's.

[Jayceh]

This allows for settings ona service specific to the implementation. EG give a feature or limit to
a service in that specific package. This is different than
part_pkg_options because it lets you have the case where you have two
services in the same package that could have different options to them with different names.

Really, I might be just duplicating effort better served by another feature in the system, but figured this might help display what we're trying to do, and will help explain what I'm missing.

This commit is for the model/controller only, it does not add any
abilities to the UI. I'd rather test this first before trying to make a
UI for it.

[freeside]

If I understand what you're trying to do correctly, you're proposing an options/value table related to pkg_svc (the inclusion of a specific service definition in a specific package).

Can you speak to the design choice of adding a new pkg_svc_option table vs. the simpler change of adding columns to pkg_svc itself? The "option/value" tables are kind of a... discouraged SQL design choice, and though we have them around in other places and they do make sense in (some of?) them, it bears some consideration.

(On the code itself, I think your FK on part_pkg is wrong; I think you intended that to be on pkg_svc?)

You describe the need for this as "settings on a service specific to the implementation" which I'm having a hard time parsing your meaning - specifically what do you mean by "specific to the implementation"? The documentation says "This is what we think my be the best way to model some of our custom options for specific constraints in a service, and still allow for multiples in a package (each with their own constraints)". Again I'm having a hard time understanding fully; I do understand the relation to part_svc, but I don't know what "custom options for specific constraints" means to you.

Can you give a more concrete example or two of specific settings or options of this nature? I'm having a hard wrapping my head what input you would like from me on this -- I see you're adding a table to store more information related to pkg_svc, but without knowing the "other end" of what real-world thing you're trying to model or what feature you're trying to support, I don't know what else I can say.

Ivan

[Jayceh]

Thanks for your response. And yes, I flubbed the foreign key since it was just prototype and not used yet I missed that.

I would say the basic idea for us is trying to support future hair-brained ideas from marketing without pushing those specific fields as being necessary on the core (added to pkg_svc). Basically the way I see it, we have certain packages, that contain several services, some of which by default have similar keys/options that would clash if they were in part_pkg_option.

Basically we need to ability to have things such as 'account_level' => 5 or maybe 'contacts' => 50, or tlds => [] to be available per service in a package. Not something is necessarily set for all users of that service, but also because of marketing doesn't apply across the entire part_pkg. And because of the number of permutations, we don't want to have a different service for each combination of these attributes.

Like I said, maybe you do have a better way already of handling this and I'm missing something, but thanks again for your time.

[freeside]

Yes, I do understand the relation to pkg_svc rather than using part_pkg_option or part_svc_column.

I would say the basic idea for us is trying to support future hair-brained ideas from marketing without
pushing those specific fields as being necessary on the core (added to pkg_svc).

In general, I would say that I would have some hesitation about merging pure infrastructure to support site-specific future hair-brained ideas outside of the codebase. Doing so is asking the project to carry the transition and maintenance costs without realizing the benefits of any actual implemented useful feature. That doesn't feel to me like it is in the spirit of the open-source community.

Basically we need to ability to have things such as 'account_level' => 5 or maybe 'contacts' => 50,
or tlds => [] to be available per service in a package.

Could we flesh out one or more of these specific needs to a useful feature that can be implemented for everyone?

Like I said, maybe you do have a better way already of handling this and I'm missing something

Then way we've handled this need is by adding fields to pkg_svc rather than creating a pkg_svc_option table. So far, that has always seem to be the correct database design choice for adding specific features.

Ivan

[Jayceh]

Right, I was hoping that a generalized 'options' that used the same common code would be the least site-specific way to approach this, eg the most open source version, allowing anybody to pass through options of their own design. To me it seems like adding extra site-specific fields would be harder to maintain, or less useful to other people.

So, given your experiences/needs, let's look at some possible use cases and where you would think the best optional storages fit.

1. Lets say I have two registrars that I work with for domains, and I needs to be able offer a package that has one or more of those, but wants to constrain usage to specific tld's.
2. I have a package that contains two services that both need 4-5 of their own attributes passed along, that will go out through the service/exports. These attributes are things that aren't a necessarily part of the generic service on its own (system level part_svc) but for that specific usage.

Now, if in the system most of our services (quite a few of them) will have the need for a bit more data, is that really easier adding columns to pkg_svc? The alternative it seemed was adding more metadata to part_svc and exploding the number of them, but I really didn't like how that went.

[freeside]

Right, I was hoping that a generalized 'options' that used the same common code would be the least
site-specific way to approach this, eg the most open source version, allowing anybody to pass through
options of their own design

In general, I have not found it a good idea to implement general framework and allow each site to "pass through options of their own design". This leads to fracturing and less sharing, as each site re-implements duplicate functionality in different, incompatible ways.

For a concrete example, I've found that having svc_something tables that represent a very specific, real-world services and real, fixed fields facilitates more sharing of code than having a generic system of site-specific svc_ tables and virtual fields.

Similarly, if the need here is for limiting the TLDs available in some use cases, let's implement that as a real, full change to track available TLDs and limit them in some cases, as a change that benefits all users of Freeside. Not a generic data-store that requires site-specific additional code to do anything useful.