[Dev] ZED for tools

[Brett Wooldridge]

I am absolutely opposed to delivering the ZED as an argument, but ultimately those who sign my paycheck may dictate otherwise.  It's a gross hack that can potentially pig memory and precludes the server from streaming the ZED through SOAP in the future, which is on my wish-list.  Once its done, it can't be *undone*.  Right now our footprint is small, and it can be MUCH smaller, but not if we lock-in implementations like this.  The hope is that the server can stream everything in the next release or two- configs coming from the NIL, going to clients, etc.  We only have two places in code where we DON'T stream currently.  We're about an inch away from a server with 100,000 devices running in the same footprint as one having a 1000.  Everything is paged, most things are streamed.

The ZipTie configuration SOAP service implements an Java interface (IConfigStore), and its an interface that can be implemented by anyone to provide an alternative backend.  We specifically designed the "currency" of the interface so that we (ZipTie) ourselves could replace the backend with something other than SVN.  NA stores the ZED, there is no reason it can't serve it up through an implementation of the interface.  It doesn't even have to implement the full interface.  In fact, it only needs to implement two methods.  When we started ZipTie, we said we'd avoid the myriad of "hacks" dictated by time and delivery constraints that over time lead to immovable code.  This is certainly one of them.  Is it more work to implement IConfigStore in NA, yes.  Marginally.  We're talking like a week to do it right, versus a day to do it wrong.  I my opinion, it's worth it.  That "week to do it right" turns into "weeks to change how it works" down the road.  We all know this experience too well (ehem).

On top of that, if we start accessing the ZED that way, you guys are going to make my life hell when it comes to security.  The intention is to apply security (who can see what) at the SOAP layer.  Only.  With the tools not coming in through SOAP, I'll have to wire up security in a different way for tools.  It's late here and I can't think through all the implications, but I will say it's already gross just based on the few issues I've pointed out here.  I will say that in addition to the solution of implementing the IConfigStore, another alternative is to simply create different versions of those tools for NA that do things differently.  We're planning to have an NA-only area in the ZipForge correct?  These tools aren't rocket-science.  In fact, these tools are so stupid it's stupid.  The handful (and I do mean a small handful) of tools that fit this scenario are extremely small - in a year, I'll be surprised if we have 20 such tools.  Providing alternative implementations is hardly painful, especially if the tool is copied and modified to suit.  Anyway, that's just another solution.  The 100% compatible-with-tools solution is to provide an alternative IConfigStore SOAP implementation.

I'm the Architect.  Do I get to make this call?  If not, my title is pretty hollow.

-Brett

On 5/30/08 7:30 AM, "Ryan Kruse" <rkruse at alterpoint.com> wrote:

Brett,

Remember a few months ago we decided that tools that want a ZED should use the ZipTie::Client?  Well, now NA wants to run those tools as part of their integration but the ZipTie::Client thing won't fly there.

Are you still opposed to delivering the ZED as an arg?  Leo also has suggested maybe providing portions of the ZED as defined in an XPath property.  So these would be valid args.

 *   {zed}
 *   {/ZiptieElementDocument/vlans}

Thoughts on how to keep this clean while playing nice with our partner projects?

Ryan Kruse
www.ziptie.org <http://www.ziptie.org/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080530/a4b5a689/attachment.html