[freeside-devel] Merge problems

[ivan]

On Tue, Mar 26, 2002 at 03:03:27PM -0800, Mark Wells wrote:
> 
> 
> 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?

Hmm, they seem to to have wound up in FS::part_export subclasses, which
seems to line up conceptually with what an export is - you call the
FS::part_export object and pass it the FS::svc_ object as a parameter.

I haven't broken each export out to its own file yet but that's the plan. 

What code do you want to move there?  The stuff that's in part_export now? 
I'd need to be convinced, I think...  What advantage do you see from
moving this into svc_Common?   It seems to fit where it is...

If you just mean the code that's in the FS::svc_acct insert, replace, and
delete methods which calls the exports - yes, I agree, it could 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.

Agreed.

> 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.

Yes, that sounds right to me too.

> 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.
> 

-- 
_ivan