[freeside-devel] Merge problems

[Mark Wells]

On Tue, 26 Mar 2002, ivan wrote:

> Exports are now tied to a particular service definition (FS::part_svc),
> have an arbitrary set of parameters and have hooks for
> Insert/Update/Delete.  Using this framework, you could actually implement
> a "runscript" export that *did* call external scripts for each function...

Looks good.  Can the export calls be moved into svc_Common?

> Do you really think these differnt types of services are similar enough
> that they shouldn't just have their own svc_ tables?  I'd be inclined to
> just have separate svc_ types for these, perhaps each inheriting from
> svc_L2_Common or something if there's code that can be shared.

That's close to what we're doing now, and it would work nicely with the
new export code, but see below.

> Seems to me you could (with the new export code) use a different
> svcpart (and thus be able to define different exports) for each of your
> different devices.

That makes sense for different devices that provide different kinds of
service, but if I have some DSL customers on Cisco equipment, and some on
Nortel, I don't want to have to duplicate all the packages for the two
types of hardware.  And I _definitely_ don't want the user to have to know
which one the customer will be on before selecting the package.

What we'd like to be able to do is use a different set of export handlers
(which, it seems, would be a different part_export_* subclass) depending
on the specific AC.  It looks as though we could write a handler that
looks up the device type in the AC table, and behaves in whatever way is
appropriate for that device.

Kristian seems to like the idea of putting the code for the AC in the
database, but I'm not entirely convinced.  Different ACs of the same type
should use the same code, to the extent that it's possible.