[noctool-devel] Re: [noctool-cvs] CVS source/docs

[Ingvar]

Jim writes:
[ I am CCing this to the devel list, as it probably shoudl be archived there ]
> Ingvar writes:
> > Some sort of GUID? It gets REAL messy, REAL fast. I've just changed (but 
> > not yet checked in) an improved GET-PROXY that uses both connection and 
> > ID to find a proxy object (one needed on each end, though the client end 
> > instantiates equipment and montitor objects as needed and link to them 
> > in the proxy object, whereas the server end uses the proxy objects to 
> > know where to send updates).
> 
> I've done GUID's before, but its been 10 years and I don't really recall 
> the issues :P :)  I'm happy to say "Hell NO!" ;)

For one, I want IDs to persist across reboots, if at all possible (this is, 
obviously, much easier with in-process interafces, though saving off a list 
with remote-node-name/ID-there as key is doable). This should, ideally, also 
survive "pack everything up and ship to new server", but as the classic GUID 
implementation use (among other things) the MAC address (well, "a" MAC 
address) on the generating computer, you suddenly lose the ability to check 
IDs that have been generated before, once the original box is sufficiently 
rebuilt (NOTE: I think they usually mix in time-of-day, in these things).

> > > 2. I was thinking of factoring out the ID slot into an id-object class and 
> > > then creating an after method for initialize-instance to throw the 
> > > instance into a hash table based on its ID
> > 
> > Better to just change the basic storage for *equipment* and change 
> > NOCTOOL-CONFIG:LOAD to do The Right Thing
> 
> Hmmm... I don't know that I agree.  I think its possible, for example, 
> that a monitor might be created by some process besides 
> noctool-config:load - making CLOS do The Right Thing seems better to me.

Well, there are examples of that already (disk-monitor or whatever it's called 
generates monitors for individual volumes) and will only become more prevalent 
(traffic-monitoring on, say, a switch will need to do the same). It's probably 
sane doing that in CLOS.
 
> I'm a big fan of "mixin" classes.
> 
> > > 3. Is there any particular reason you chose to use uninterned symbols for 
> > > the IDs (GENSYM instead of GENTEMP)?  
> > 
> > Yeah, kinda. It's guaranteed to exist on all lisps and we're essentially 
> > doing string-compares anyway (ooops, need to fix that in the network 
> > code). As long as we're OK with having only locally-unique IDs, we could 
> > fall back on a plain counter.
> 
> Well, we're using Common Lisp and GENTEMP is part of the standard 
> according to CLHS.  Also, I think we should be realistic about targeting 
> *ONLY* SBCL for the first (real) release.  If it doesn't work with SBCL it 
> doesn't work with Noctool. :P
> 
> Why I'd wanted an ID to be an interned symbol is that it makes it so much 
> easier to convert from a string given by the user.  The other way to do it 
> is to hash on the symbol-name of the gensym'd symbol - that actually is a 
> tad more efficient since I don't always have to convert between strings 
> and symbols.

I am thinking that we should move to using (one or two) plain counters, as 
we'd have to make sure there are no ID collisions after un-persisting stored 
data.
 
> So, In short, I no longer care if we use gensym or gentemp. :P :)
> 
> I think my arguments of if its in the spec its fair game and if its 
> supported by SBCL its fair game should still be considered.  (If its in 
> the spec and not suppored by SBCL, I'll take the abuse and submit a bug 
> report ;)

Yeah, SBCL first, the world later. :)
 
> > > I'm thinking about the web interface stuff and, man would I like to be 
> > > able to look up a monitor by its name for the purposes of the GUI...
> > 
> > Name and ID are different, though. The name is supposed to be human-friendly 
> > and the ID is supposed to be code-friendly (with the obvious problem that 
> > human-friendly doesn't necessarily imply unique).
> 
> OOOPS!  I was speaking /far/ too losely :)  NEED MORE COFFEE!

Can't have too much. Speaking of that, I realy should get some lunch.
 
> I want to look up a monitor by its ID, not its name.  (I probably also 
> want to look it up by its name at some point, but... )
> 
> > It gets even bizarrer with monitors, since they don't (strictly 
> > speaking) have names, they do have associated equipment objects, though 
> > (and they have names).
> > 
> > I suspect the best (as in "easiest", not necessarily as in "technically 
> > most superior) is to have something akin to:
> >   http://noctolweb/equipment-by-name/jprewett-server-17/ping-monitor
> > 	This looks up jprewett-server-17 (a piece of equipment), by name and 
> > 	spots that there are more stuff after. It then checks the ID and 
> > 	builds a new URL and redirects to
> >   http://noctoolweb/equipment/EQ-42/MON-872
> > 
> > That way, you tend towards persisting ugly (but fast-to-render) URLs, but 
> > still have an easy way of actually finding them.
> 
> Thats pretty much what I was thinking.  Your suggested URI's are 
> remarkably simular to what I was playing with yesterday :)

They make sense, in some sort of human-readable way. 
 
> I'm intentionally *not* looking at your X11 GUI until I've taken a first 
> stab at the Web-based one.  I don't want to be biased by your interface.  
> After I've got something I'm reasonably happy with, I'll take a look at 
> your X11 GUI and fix all the things I flubbed ;)

At the moment, there isn't an X11 GUI. The closest you get is using either an 
XLIB:DISPLAY or XLIB:DRAWABLE as a sink for IMAGE:EXPORT-IMAGE. 

//Ingvar