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