Road in a mountain pass

Tuesday, January 02, 2007

END OF ROAD

Friday, August 18, 2006

"Nothing more headache-inducing than documenting the thing"

So, I'm trying to educe the first major source-code import to the Tioga Auxiliary Library codebase. It's being derived — this one, and some probable imports to come — produced on some code that I've been working on for the past few months.

In the process of importing the code, I am also requiring that every form added to and exported from the tal package will be documented. This is onto a new paradigm I'm trying, the metal shop approach to software programming._[1] There are so many parts to it, such that I can determine:

Know what you're doing.

Plan it up.

Hammer it out.

Finish it up.

Take a look at it.

Consider what you're looking at — taking it not as for to leverage an attitude of pride by, just simple candor — looking at the matter, with a close eye to the thing, looking for any problems, any glitches, anything appearing odd to attention.

If appropriate, refactor the work

May want to document the matters, then — if it was not documented, on through and throughout. Some things, you won't recall at when you look back to it, if just by looking at the thing..

Ensure that it is done.

Move the thing onto the done shelf (no marketing, there — materail, on shelf)

Marketing? PR and press releases, scheduled etc, "something of another department."

The first and the sixth points, in that list, those are of the most crucial to the going of the work. The first is the most important.

To work on the thing, as so that the work would be effectual to your intentions, you should want to know the thing, first onto the more. To an approach about "getting to know a software system", but one would probably direct one's attention onto each individual work, in a distinct manner. Some documentation may serve to help, there — even auto-generated docs, as you'd be getting to know the system.

At the outset, it boils down to a matter of knowledge, material, and tools — tools, as in what you apply onto the material. In a most primitive term, that is to the making of work.

later : {No thread}

[1] There is a caution, against calling a worker of a metal-shop either clumsy or careless.

Some workers — as workers in a shop — would not respond, visibly, to an insult.

Some would respond, clearly; some, with no more of patience.

If were one to not be careful, as when endeavoring to be in a mechanical environment, one will wind up in much pain.

Patience is not a commodity, but it does occur with an end to it. Trash-talking — a behavior, ill in intention and in form, bearing not much exposition, though some would run their mouths, at it — it tries patience, before an end.

Vain junk of an attitude, it wears on what sense of restraint may retain a calm.

There may come to reside to a person, a condition in which there would appear no evidence of civility, no appearance of fairness, little of reason, and none of hope. There may come to reside, to a person, such an appearance of community, but ill, defunct, dead, helpless and hopeless. If come to set with it, some people may go weak, in response to it. Some people would cut their lives short, in unreasonable ill, and some would not.

Some would bulk-up, working up strength and keeping it worked out. Some would not be afraid of bowling anyone over, then; some would lend off a warning, upon offense occurring — offense occurring, offense made, and a warning sign set out.

I've met one guy, one bulk of a person who you'd be careful around — might have an easier time around, true, if you were to a browner skin born.

I had been met to the guy, in work at a construction site — another person, then showing up in the day's crew. Ain't much to say of our trade. That day, the job: Move stuff around, out from the trailers, onto the floor. Whatever their trucks brought in, our job was to move it out. Sidebar or not, it was a job requiring of no pretense of attitude or of behavior.

I did not know the guy; he was new to the crew. No matter to my attention, then, but as another person on our job.

As it came to be, then, there was a matter of the hand-trucks and the carpet.

I had not intended to make any pesonal offense to the guy. It was an instruction, made as such that I'd knew of, and knew that he did not know — he was not in the audience to it, had arrived to the matter, later on, and such and so-on. I observed, it was my responsability, to bring the matter to his attention. They had instructed us to not move the hand-trucks across the folded carpet; he did not know of the matter.

Of the one guy, the one — may I say, a guy become somewhat more reasonable, at least by the time of the end of it, in what I came to know of it — at the outset, of his response , I was surprised.

In true, I was surprised of his response. Not had I meant to offend the guy. He was offended. His response was of a threat.

In my initial response to his response, it was about so, "You'll do what? You'll _____" then repeating what he threatned, loudly, with no anger. There were the crew of other contractors, in the area. I had wanted to be sure that the thing could be recognized. In case it would have become to a poor conclusion, then at least anyone in the area may have known aught of what it was. He had the muscle to carry out his threat, but I wasn't afraid of the guy; his threat bore no tone of any stab you in the gut kind of wicked intention, it was a fight that he was threatening to. He wasn't a one who would take a weapon to it.

Had I let that a fight would become of it, but that wouldn't be how it went. There was fair opportunity to prevent it.

To be sure, I became worked-up, upon the encounter. "How was I worked up?" would anyone wonder? I was worked up to a damned solid state of certainty, there was not going to occur a fight. ("Aww shucks?" No boxing-match to the reader, no mutual waste of time, let alone how it would have rocked the site, the other crews, and left some other doctors in a hopstial somewhere, getting two hard-up individuals to fix up.)

The most that I figured I could do, I told the matter to one of the lead crew of the site. I was, in true, on a team of overall laborers — and some of the junk that we had to take care of, I will not go far into, but that it was some ugly cleanup, and there was some minor, "unskilled" work, and some moving of some ridiculously heavy s_, some "fixtures", made of the wrong damned kind of wood, stinking compressed sawdust and glue, cheap in price and material, but "deemed viable" of who was at the drafting-board to the thing — painted over, then, or surfaced-over with laminate, some compressed-sawdust wood — some fixtures, some short and some tall, all as heavy as work made of iron — the largest, requiring of a team of five men and mechanism, to move it a foot, let alone to move it "upstairs (with no elevator large enough to fit it)" — the mechanism, then, done enough — ramp, wheels, and heavy lifting. It sure as f_ ain't like a walk in a ballpark.

Not to fixate on the fixtures, but there is a point to this. It was their contrivance; it was our burden. Someone, wherever it was, someone up in an office instructed the cabinet company to make the things of that material, and took those specifications, to it. I doubt they even saw the things — specifications sent, material assembled and shipped off, biled to "accounts payable", billed of "accounts receivable", "their end of it".

It was our job, to move the damn things. Even pine would have worked better — something not that concrete by-product of a lumber mill, the material all through the fixtures. Head detached from the hands, their shop was assembled, alright.

Ain't a one of us payed well enough that we may take long, in speaking on it — "design hacks", burdensome decisions of someone far off, tirivial and mundane approaches in the construction of a thing, "passing inconvenience", and naught for any labor to become any more skilled by, contrivance.

One could say, "We are not as hard up as (were, and ever are) the people to the communist republics". We do not get put into forced-labor camps, en masse, on mere leverage of politics — nope, it's all voluntary, here, with what pittance of a salary before cost of living.

Steinbeck's is the closesest matter of content I have known of, such that may even serve to make an impression — even nearly compared to that of Alexsandar Solzhenitsyn. We get no spokespersons but ourselves; some people are too spoiled to hear it.

There might be, then, the song in the trenches. It sure ain't a lullaby melody. In and beyond the regard, SlamJamz is one label of good material.

The guy, then, the one who appeared to have been hurt of the tone in which I had recounted the instruction of the place — his response, made in a gesture to a threat, as true as a hawk ain't confused of what he sees — as I said, I explained the matter to a manager.

Whatever it was, which the manager had said to resolve the guy's anger, then the other did approach me, later that day, and apologized.

To be sure, there was no sycophantery in it. His apology was genuine enough &mdash seemed strained, I admit, but mostly sincere. It was clear enoguh, that much was worked-out.

It so coincided, that I was standing beside the manager of the site, at the time when he was informing the office of that our crew was to be recalled for the next day. There was an item of paperwork for him to sign, of the day, so I had to get it done. It was such that beacme an opportunity, then, for my to mention the apology made of the other, and that I was not worried of it. Next day, the guy still had a job.

He was there, for some few more days — hard worker, he could be good humored.

Sometime later, he did not show up, again. If he would have been recalled, I'm certain that he would have showed up, so I don't know what became of the guy. Around Fresno, who knows. I ain't so concerned of it.

I am certain that, the manager would have become aware of a concern, the concern to my person, upon that unusual event — let alone, that the guy had apologized, on that day — but a concern, if I could be taken as a target of blame, to him, if he was not recalled. I could not expect the other to make long ends of it, if it would so appear to him — no vindictiveness in his character, just that temper, such that a person may have a job aside of, to resolve of one's own.

The site's job was reasonble enough, in a work sometimes strained to be so.

It is just so, I have not met, again, with the other guy; I expect that I will not.

Judging by the bulk of him, his extensive decoration of tattoos, and the anger he had found — triggered, of an expression that he had taken as offensive, but then restrained, of his will — in all, upon beholding the guy, I figured that he has probably been gone through the jurisconventional wringer, courts and jail of the area. In true, I found a sense of concerned, for him. Ain't no joy becomes of a jail. Ain't no reasonable joy I can find, of this city. Then, that work, it is a paying, dead-ending vocation — on again, off again — "general labor", and it is hard enough to come by, let alone if you'd get tossed from it, on a mean ordeal.

There is some anger, may have grounding to it. There is some fairness, may get measured in at a cause. There is some response, overboard; one might wonder what the hell would be the full cause of it, then. "Not my concern," much, to the issue at hand.

There had been some tone in my voice, such that — I recognized, after the matter — it was, most probably, what stood to have pissed the guy off, a tone of attitude, "I'd thought it was trivial," beside that it had rode on an instruction. The instruction was to us, and every person working beside us, in more. The tone of it, I could resolve. Wasn't much, to it.

In the apology he had made, then, there was a show of respect — surprising again, even in as much as it was — enough to that my primary concern was resolved, before the next day of work.

Experience, occurring to cognition — experience, as a phenomenon that may occur in gain, upon a work — experience made to consideration, it is such that you cannot mark a dollar figure to. Small surcease of wages that it may be, then, but in how you'd apply what would have been gained of experience — if capable of determining a gain, of the endeavor, such as some endeavors may not afford, but some do — no equation suits it. There is no measure for experience; there is no conversion ratio into coin.

Neither does a mark on a resume equate, much, to a relation of experience. There is something else than a resume, that on which an interview is made.

[2] "But how can I follow that up? Gone ran on, etc, said of my own person, I."

A rhetorical question: What project does not involve a diversity of languages?

Just of what's being used in the Tioga projects, a list:

DocBook SGML

No custom DSSSL, at this point, but I may work-in some DSSSL, to customize how the documentation gets output. For now, it's the body of the upstream stylesheets, and little more. There's a dim potential of SGML-to-XML conversion, then how-much code, just for the processing the input, and how much for generating the output, even onto one documentary format, but via Common Lisp — "woo", but it is stuff that goes nowhere to the project, now. There is not even a promise of producible results, of it -- and too much to mangle in the process. I'm not going to loos the discursive, CLHS-style sections to each refpage; for now, it's manual markup. Some template workup with SLIME, SLIME's SWANK, and CL-XML should be viable; might have to cut me some slack, here.

HTML, derivative of SGML

SVG code, if just for the logo

PNG code, for delivering the logo to a typical web-browser.

CSS — in the Cascading Stylesheets kind — in adjusting the formatting of the few web pages yet made to the project

Emacs Lisp code – nothing slated to be moved into a public source-tree for it, but some of it should get worked-in.

Common Lisp code — in the least measure of what's being written of the project, and this kind of code, it is the point of the project. "Lines of code in formatting and content for documentation" are outweighing "lines of code", here, by far.

Eight formats, two programming languages, one project — nothing to say of what all the tools, applied for it, are coded in. There'd be C, in company, then, and shell-scripting, and makefiles, probaby also some Python. At least eleven/twelve formats, by now — five or six of which are recognziable as being, in each, a direct input for a single programming environment. Such an assembly then, it is taken as "typical", is is not so?

Somewhere across it, one line. Weather shows a slight chance of showers. The road's been washed out, before — I got over it.

One metal shop — some other sites across the way, true. "I"m just the delivery guy."

and a road I won't stare down, for long.

There's a basin on the other side, a salt pond along the way, more mountains on the yet-other side.

Somewhere along it, there is a camp — about fives miles back, yesterday. This is some rough terrain.

A long distance haul, no more mistaken as chautaqua — but to keep with the shop metaphor, it may be the more viable.

Thursday, August 17, 2006

TIOGA - ROADMAPPING

It is fesible to represent a body of information in XML, but representing it in such a manner that it may appear impossible to represent — to a systematically comprehensible effect — if as input to a normal object system.

ISO Topic Maps [official ISO specification]

may bear some association to the following

XML Topic Maps [TopicMaps.org specification]

may be used for associating a number of user-specified topics, in user-specified associations

will depend on XLink support, within the processing environment (i.e w/i the OS process in which the input would be handled, or w/i the reader's center of cognitive faculties, if a person would read the XML file, directly. We are, one could say -- whether it would be accurate or if it would not be, the assertion -- we are uniprocess organisms (?))

Here is an inline representation of the prior:

XML Topic Maps may be used for associating a number of user-specified topics, in user-specified associations.

Processing for XML topic maps will require support for XLink linking (somewhere of the W3C is the standard published for XLink).

Then why would topic maps be used for such? The "topic-map user agent", as a client onto an information system_[5], it may be used in accessing material about the topics that would be presented in a topic map.

Hypothetically: XML Topic Maps, in application, be used for representing ontoogical categories and ontological category members. Here is a working, albeit incomplete_[6] example of an attempt at such:

<!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Maps (XTM) 1.0//EN"
"http://www.isotopicmaps.org/sam/sam-xtm/xtm.dtd">
<topicMap id="svoutline">
<topic id="tr69-service">
<baseName>
<baseNameString>Service</baseNameString>
</baseName>
</topic>

<topic id="tr69-service-cat">
<baseName>
<baseNameString>Service Category</baseNameString>
</baseName>
</topic>

<topic id="ontocat">
<baseName>
<baseNameString>Ontological Category</baseNameString>
</baseName>
</topic>

<topic id="cat-dir-member">
<baseName>
<baseNameString>Direct Category Member</baseNameString>
</baseName>
</topic>

<topic id="tr69-4">
<instanceOf>
<topicRef xlink:href="#tr69-service-cat"/>
</instanceOf>
<baseName>
<baseNameString>Technical Engineering Services</baseNameString>
</baseName>
</topic>

<topic id="tr69-4-1">
<instanceOf>
<topicRef xlink:href="#tr69-service-cat"/>
</instanceOf>
<baseName>
<baseNameString>System Engineering Services</baseNameString>
</baseName>
</topic>

<association>
<member>
<roleSpec>
<topicRef xlink:href="#ontocat"/>
</roleSpec>
<topicRef xlink:href="#tr69-4"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#cat-dir-member"/>
</roleSpec>
<topicRef xlink:href="#tr69-4-1"/>
</member>
</association>

</topicMap>

The TR69 referenced, there, is ECMA TR/69. (I suppose that I should represent that within the topic-map document — but I would rather {EOF}.)

I suppose that I should represent the orign of that reference, in something supportive of a bibliography. I am aware, there is RefDB, but I would like to use the lisp image as the whole of the database. To do as so, then, I should want for something to serialize a portion of information contained in the Lisp image, onto a persistent substrate.

"yaddahdah yaddadah" notes on paper "yaddahdah yaddadah" trasnscription "yaddahdah yaddadah" ecrypes, some bad memories.

"yaddahdah" a design for a system using serialization services in storage of information onto a file substrate. It -- at the design of it -- would be applicable for managing serialization onto any sort of normal, storage service, viz a viz an SQL service, a remote ORB service, if not a kernel-accessible filesystem service.

That it would be operable for such, there must be defined -- no offense, for the shortness of the following -- some stuff, some stuff not exactly trivial.

What I consider may be servicable, about it:

a class value-domain (the name of which may be subject to revision, as the design for this would be worked out)

a generalized means for marshaling and unmarhsaling of values, across an interface onto a value domain. The interface, as such, it could be constituted of CLORB. It could be constituted of CFFI, as towards the CFFI-Sys domain. It could be constituted of CL-SQL. While I am not much familiar with the "guts" of LDAP, in enough to know if a system implemented according to the LDAP specifications would be supportive of an exacting set of data types, beyond (or among) those that may be used in the facilitation of an LDAP transport mechanism, but maybe CL-LDAP?)

as such that (probably) would be made within the marshaling/unmarshaling mechanism: A type-driven mechanism for translation and (or, rather) import/export of values. (It may be called "translation", but it occurs to the production of new information, with the original information remaining unchanged of it. There is production of new information, ocurring in translation, as of "input", as onto a single "output" -- however many outputs would be produced, on the base, the original form of an item. I could prefer that it would be referred to, then, not as if it was something resulting in the loss of the original information. It is not "transformation", the process of "translation", or of "marhshaling" of values onto an single substrate.)

Then, you might care to know: Why do I like CORBA?Why does CORBA appear as something largely appreciable, to me? It is, in part, because the design of CORBA -- in when I have observed what I may of it -- it has served to help me, in resolving what was a design for a serialization mechanism, resolving it as if "across GIOP", onto something applicable, without so much system-specific "obfusctififcation".

Then: CORBA may be extended, so as to be supportive of what is not written into the gap, between this and the prior.

In that margin: Representation of values in a manner that may be particularly suitable to a given Common Lisp implementation, viz a viz bignum encoding in CMUCL and in SBCL, and fixnum encoding in the both. On a fixnum, then, should one store just the address, or the numeric value? One may be computed on the other -- though as for how that would be , on a negative fixnum, I had not guessed right, if on the first "run of guessses", a very trivial prototype, as trivial as some few symbolic expressions, nothing that appears to be "lost", some attempts at translating a negative fixnum to its address (simple, there) then translating the address back to the original, integral value, then without using the same mechanism as the prior. Maybe I have missed the encoding algorithm, again, but I wonder if it is produced with the range of bits being all set to one, first. Perhaps I will recall the question, next time I'll be about the matter of it.

CORBA may be extended to support an implementation-optimized protocol, such that would be implemented as to operate in place of GIOP[X]. Even as this is written, some members to the OMG have been -- perhaps, at this moment, are -- working on finalizing a draft for a proposal, such that (I am certain) will serve in explanation of how they would propose that something would be implemented in place of GIOP, within the whole CORBA architecture.

[X] and may utilize, inasmuch, a mechanism implemented onto procedures for shared-memory access[Y] [ZE]
[Y] such that would be supportive of IPC, on a one kernel[Z] host[ZA].
[Z] operating-system kernel; representative (as the manager) of a discrete group of processes.[ZB]
[ZA] "virtual" or running, most directly, on the processor
[ZB] threads of execution.[ZC]
[ZC] One might make reference to SSC, the Shared State for Common Lisp project.

[ZD] as onto a whiteboard

[ZE] and, similarly, onto procedures for socket-file-driven access[ZF], at which point, there would be an encoding onto streams[ZG]
[ZF] supportive of implementations not supporting a shared-memory method of access, but such that would be executing on the same host
[ZG] possibly, in a manner much the same as when it (the stream-substrate driven encoding) would be addressed onto network sockets, on a given (type of) network.

[ZF] "Dietary requirements of the writer notwithstanding", viz a viz nutritive material

[ZG] In a file-based encoding, i.e a file-substrate driven encoding[ZF] -- such that may be made within a discrete architecture for such, however the definition of the architecture would be made -- the mechanism for the encoding/decoding need not include all properties that would be required for a peer-to-other-process communiction. It would be enough, to ensure that the values may be encoded and decoded; no handling need be done, for making a "peer link" with another "peer", in it.
[ZF] associated with pathnames on the files -- and also, associated with stat st_dev and st_ino qualities, to the point of a kernel-host-unique, per-boot-session identifier on a file, regardless of its pathname, those two stat qualities, when assembled into a single structure.

Filesystem pathnames are made on a convention for the sake of the user.
Across a given period of time, a single filesystem pathname, on a single kernel host, under a single configuration of "mounts", identifies zero or more files, as on a single filesystem partition.

A mechanism for fcntl locking should be made with something capable of noticing "what is the same file", in a manner regardless of "what is the file's pathanme". Whenever a file-stream would be closed, any file-region-locks still standing, in that os-process, onto files with the same {st_dev,st_ino} set as the closed file, those locks must be renewed, to the kernel, or they will be permanently lost. Even within the duration between when the lock is lost (and when the system-call for closing the file has returned) and when the lock would be renewed, there would be a potential for that another process would have taken the lock -- the process originally having the lock, then, having lost the lock to the other process. The implementation of the file-lock-driving mechanism should be implemented as to support application programmers in handing the condition. That mechanism, it should be addressed firstly onto the streams architecture, within the given programming environment onto which the implementation would be addressed.

File-locking may be of a necessity, when there may be two kernel-host processes simultaneously accessing a same, one file.

Somewhere onto UML -- in OS / Linux / User-Mode Linux -- perhaps there may be addressed a model for the modeling, a model for the representation of kernel, in an class-instance environment.

and documentation. To survey is one thing. To map what is learned of the endeavor for survey, another.

If something better than CORBA may be done, something that might be done however like as CORBA, one might want to wonder if it would wind up as DCOP. or MCOP. if not as CORBA.

Perhaps it would be clear, as for how it could be done, and clear, when it would be addressed with consideration of CORBA -- perhaps, without leaving the implementation at the point of supporting the OMG's IDL-Lisp bindings. Much of what is represented in IDL may be represented with MOP, with virtually no additional burden to the developer. To propose as such onto an existing project, it could be as to propose something that may be beyond the pale, a substantial redesign of someone else's system. I do not know how a fork of CLORB would be taken, and I would mean no offense, if by forking it, but it could be more effective, to derive a separate working branch of it, as a basis for an initial implementation. So it is, then -- into a TLA archive, two branches, one from the CLORB baseline, one from the local development, the former not meant as to rob anything from anyone, but to maintain consistency across systems.

Somewhere along, here, there are defined three types of codeline development branch

Baseline development branch

Prototype branch

Mirror branch

In more, there would be at least this one more:

Sealed (Released or otherwise Finalized) Branch

That much would be of importance, at when a branch would be managed.

A fork: A prototype branch (as may be contrasted with a baseline development branch -- as for a typing of "portions of a codebase"), then approached as it having range to become disjunct from the baseline. SBCL was originated as a fork on CMUCL; any concer about politics made towards the prior -- discursively, in above, the latter, pragmatically the prior -- might be resolved, on the consideration: There is clear note of the origin of the code, even in proximity to the license text. So, it would be that some expressions of personal attitude had been written into the codebase.

Harumph. and it is such expressions that I will have scrubbed from everything I will import into the Tioga projects' source archives, expressions of opinion, some-odd annotations of the code, put in the wrong place for it -- in temporary location, before the code could be published. Such annotation should not be necessary, may be apparent as it being not necessary, perhaps when one observes, the potential for addressing the matter into normal relation, in documentation of one's intentions, of one's determinations, of the requirements to the matter -- those recognized, if not those not yet integrated into the design of the thing -- upon one's considerations -- if not, of a given implementation. It may require some patience, some will for it, and in the while, it may require some recollection of the material.

To document a matter, it may appear, ever, as an interference -- how else can I put it, but that it would appear like "interference"? -- before more work would be made, towards and in implementation. Documentation is not -- by the character of it, cannot be -- as systematically productive, as discretely productive as may be a portion of code. One may enjoy writing code that works; one might consider a documentary system as it being irrelevant?

{named-object-type-identity, {name-symbol-package, name-symbol-name}} - applying an algorithm on that set of objective values, one may produce a reference to an item. The consituents of that set would be produced of the type and the primary, symbolic name of an object.

Ok. One can do it with OIDs, and that's enough to have it done.

To have it documented, then, I may as well start on the documentation. End of page, middle of page.

mirror the CLORB archive

define system tal-ident-oid

work-in the Tioga Project's assigned OID
- OID registry - extend the type oid-node; beside the integral value part, and the fixnump flag on the wrapper object, also define a value reprsentative of a primary (base) character-string label (viz OID-in-ASN.1 encoding), and any additional string labels (in a separate list), then, a common-name for the node (a human-legible label); denote that each node will be given a distinct type, oid-node being one baseline (protoocol) type. Define some example oid-node types for e.g "codebase", "host machine", "codebase-constituent file" (screeeeching at the point of resolving a relative OID onto the OID for a codebase -- finding the OID for the codebase, the first issue) and how OIDs would be mapped onto classes (standard classes, even, of which the foremost authority would reside to ANSI for defining the OIDs, though prototype OIDs may be utialized) and slots, and a 'type' not singularly defined of a class, and a function (coincidentally, "all the stuff that IDL can be mapped onto") and a CLOS method,/li>
- notice that the utility of a mechanism for mapping OIDs to objects, it will be limited onto the set of registered OIDs. Tioga Project can have a policy for assigning OIDs to other projects. Consider DNS name registry, as for what would have to be handled in the registrarion. Make reference to the material upon which, the obtaining of the Tioga Project OID is predicated -- IANA, and why, why there are maintained formal, normative, constant registries of names (and numbers)
- Propose "OID" as an IDL repository ID prefix; leave a mark for as to support it, in the fork onto CLORB
- somewhere, map it onto forum and releases
- consider the utility of CLIM-driven representation of "OID-node" values
- observe that an OID represents an "arc", in the form of an identifier
- recall that this is supposed to be implemented onto tal-ident-oid
- an OID may be "resolved" to anything more than an OID identifier part (e.g. the token 5 or the token "pippin"), by "resolving" it onto another OID — the driver function, resolve-oid, it must return an OID, or must signal an error.
- Begin maintaining the Tioga Project's OID registry

(flipping disjunct from the prior) define the codebase branch types. observe that they will be as types for abstracted objects, without regards to SCCM system type

"mumble mumble" XTM?
- Implement an object model for -- hey, how would DOM relate to this? DOM is the Document Object Model in XML. (Some vaguery about DOM, in a CL implementation, follows) The XTM DTD provides some structure, across an DOM instance ("an DOM instance", "an instance of an object structured as per the DOM specification"). The "DOM-factory" viz. CXML, in that one function, cxml:parse-file. mutter mutter, stuff to look into.
- recall that XTM may be of help for helping people to make sense about, after, beside, and/or without the Tioga project
- observe how CXML will be relevant for supporting the CORBA component model (CCM) onto the baseline decided as to be derived of the CLORB project's ORB and IDL codebase. (Much respect due, there, no doubt -- hard to fit that into a terse outline) (To not expect people to be "touchy", as upon a grounds of sense and cause enough to respect the other, that is an origin of repsect -- and when finding no grounds to respect the other, better to disregard the other, when "at all" reasonably possible -- simple matters of civility.)

MOP into CLORB - a refactoring of the stuff to the CommonInterchange codebase, onto the fork proposed to be resolved of the CLORB codebase and denoted per all fairness and the CLORB project.

??? value domains ??? system domains ??? system environment on the "in" side, system domain on the other ??? _[M]

distinctualize the parts making {IIOP and GIOP} happen (like as many, it is a layered protocol, however trivial to mark the layers of -- "IDL ... on up to GIOP request/response", then "on each 'other side' of the connection", in the operations of an ORB)

the OID resolver (again, "disjunct from the prior", such as in this being an outline), in operation within {EOF} in operation within an OID-resolver-driven query-peer-for-determining-the-object mechanism, it would be usable for operations, in that mechanism. In a normal-response packet: Upon resolving an OID to an object, a peer-local (viz. like with CORBA, the address would be peer-locally-unique) address, encoded according to what byte-order? (again, like with GIOP, the byte-order may be "resolved" as between the peer and the server -- whichever of the two gets the primary 'say' about it, I am not presently aware. The book of "Rules of the game on the CORBA field", it is non-trivial in extent, and may be subject to subsequent revisions.) In exceptional-response packet: A bit indicating "this is an exceptional response packet", then what would be the contents of that packet? Again, GIOP, IDL, and any more of the related parts of the whole CORBA architecutre, may stand as for reference -- regardless of that there's something to say, somewhere, about peer identity and authentication of identity.)

[M] : User-Mode Linux; 'Kernel' Modeling - on into 'device' modeling, at this point, venturing into the systematic body of the Linux kernel.

Bibliographic {overload} on the TDoc project.
- a mechanism for recording of resource authority records - in the least, something for mapping an OID to a non-OID-encoding URI (viz the OID URI namespace, a URI may contain an encoded OID; the specification for said namespace does not include a constraint on the 'size' of the integral elements to the value, but that they are unsigned, and yet, one may exect to encounter mostly fixnum values; it is like some kind of an oversight, and is resolvable with something about typing and -- for sake of reasonable, wholly viable optimization -- type-flagging)
- (aside, this becomes the definition of a resource database system - may be used for a production of bibliographic information)
- a 'resource' class ?
- a 'book' class ? (superclass, a subtype of resource, per an ontology for resources)
  - isbn : (or isbn null) : nil
  - locccn : (or loccn null) : nil
  - TITLE?? HUH??? by whose authority? AND IN WHAT LANGUAGE? (MSTRING?)
  - bibliographic info — somewhere before this, modeling for DCMI 'terms', and object-types for it, and such; might serve to a resolution of questions w.r.t resource titling; should serve to affect a means by which how an ISBN and/or a CCN would be input
  - something identifying the authority on the record. or the source of the record. OID?
- an interface for ? (Option 1) extracting a static XML representation of a bibliographic record, per the definition of a static extraction mechanism (that resulting int he production of a particular type of reference, e.g. for insertion into a bibliography element in a DocBook document; something similar, I have read, is producable of a RefDB service. I consider that there is no grounds for sweating the derivation of a design, across free/open source projects -- and no cause for anger of offense, when the matter is denoted.) (Option 2) denoting a given resource record, within a document, using only one markup element node, in the denotation, and an OID for the identified thing (in this case, the 'thing' being a resource or a resource record -- the identity of which would/should be determinable by the preprocessor) the OID for the 'thing' being encoded within an attribute value (if in a document-driven encoding, then encoded, using a URI, and resulting in an error if the URI schema in the value, on "input", would not supported by the preprocessor; if in a regular-object encoding, then just as an ... object, such that would/must have an OID defined about it); that would have to be used in a system supportive of "preprocessing", as in situation before the structural stuff of a document would be processed in generation of other formats (HTML, PDF, and otherwise).
- mumble mumble (crypes this can run on, a design session, occuring as to cover a substantial field) something for processing documents to produce things in other formats. consider the operations of a DSSSL processor, in traversing the 'groves' of an SGML input, then producing 'flow objects' of a DSSSL intermediary, those 'flow objects' (those 'flow objects' then being used in the generation of a final, file-substrate output.) (Some stuff stays buried.)
- how the heck, back onto XTM? The thing could have a web-based interface made, for it. topicmap, topic, and association elements could be served-out in transmission of individual XML infoset document-portions via HTTP; each servicable portion could be made available like as a DAV collection, the contents of which would be presented for sake of user-agents as inclusive of XSL "fun". Kerberos authentication could be required, so in order to allow access to the service; without the authentication, it could occur to the feeding of junk of trivial, inane, google-muxing systems, people spidering the resources, then republishing -- such that is already being done, in non-disclosing, clear (and sometimes, broken) rebroadcast of the ("open") contents of Wikipedia, one matter by the wayside, but it's been observed, here.

Somewhere before the prior, something about Kerberos -- the MIT or Heimdal distribution, one or the other, but for purpose that will have to be denoted, firstly. must be supported for HTTP-U.A auth. and for ORB auth. Should be part with/to a simple user object model.

file locking??? off in the tal-os-file domain ?? doevtailing with simple-streams efforts, for the {st_dev,st_ino}-driven registration of file identity, and the on-close-reinitialize-lock behavior ??must check onto sb-simple-streams

signal handling ?? "if this 'blog client crashed, I'm nuked". GNOME bug-buddy is capable of Doing something after an app would segfault (segfaulting -- how is that noticed by a process?) ... to the effect: There's soemthing that GNOME bug-buddy does, after an app (process) goes "kablooey", then assisting the user in (if necessary) making a bug-report on the matter -- by that end, to the effect of a BTS, probably using Bugzilla. To do : Study up on segfaulting, and determine how a segfault would be noticed of one process, but noticed by another. It should not require a trivial "app-ping" protocol.

serialization ??? fit that in with the CORBA-related work - file substrates, managed by encoding services manaring encoding clients

referring to the OID support: For purpose of supporting OID-applying development projects, specify a part of the Tioga OID project, a particular numeric "group" of OIDs, for assignment to project staff members and other ... eygh. IDENT. "Nothing saying, right". (Then, start mapping OIDs, one onto each of those photo-negative sheets. Here, it can dovetail with a photo DB -- one OID for each negative batch, the negatives of the shots, printed on metal-oxide cellulose film; that "negative-batch" (film-spool) OID as the base OID for each mediate form of each shot in the batch. one OID, then, for each 'negative' copy of the shot. one OID for the official digital representation of each same shot. then what about audit trails? X makes shot Y onto roll A, has roll A developed by Z. Z returns processed A and perhaps some prints B and/or contact-sheet C of A, returning these, ultimately -- gaps in the line, there may be, and each one might be awkward to identify -- to X. or, X has roll developed by Z, and Z returns a CD-ROM D with shots of A, as well as the developed A; before developent, A is in one state of condition, then the same material is subjected to a chemical process, whereupon the substantive condition of the material of A is changed, from "shot film" (after it was "not-shot film"), to the effect: (Non-light-sensitive), 'devleoped', finished negatives; how is the property-change in A denoted to the system? It is the same A; Z is given authority to change the state of A (after A has been, in any part, changed from not-shot film to shot film, by whom would have taken each shot), but that cannot quite be denoted of a roll of film, "only Z can develop this"; A is not "edited" by Z, but the state of t is changed. A is developed by Z, and what is developed of A? Molecularly, the composition of A is developed -- some material becoming removed from A, in the process, and some of that will be some various molecules, in the matrix of a mildly-noxious, inherently poisonous chemical; A would be of a quality of object being capable of a characteristic of dynamism, and material -- non-abstract -- and capable of being subjected to discrete changes, those changes being representable as per quality of medium. Yet, the media of A is not changed. The mdeia of A is "film". "Film" is either "developed" or, one could say, it is "raw". A is a roll of film; every shot produced of A is produced of the same medium, and the same type of medium, but is abstractly disjunct from the medium. Of a biological organism, the "medium" (?) is the person, or the creature, but would be represented as the one's body, the one's physical form -- physical organisms, in all, are subject to change. However a person is represented, film is a medium; a photo is an abstract thing, a discursive phenomenon, (not subject to change, either, though "editions" (?) "issuances", "releases", may be made of it) represented upon at least one medium. I may want to record, somewhere, who has developed an item of fim -- would ask the staff of the developing studio, "Pardon me, but may I have your EIN?"? No, an EIN is also a TIN, as is an SSN, and SSNs are sensitive w.r.t identity theft, so would not be something that one should want to have people to transmit. An OID mapped onto a resource record, retreivable according to type of represented entity and other qualities of identity, then maintained of whom would be keeping the resource database, ie oneself, or one's agency.) (A roll of film: Type of 'mediate-object', subtype 'photographic film', subtyped per manufacturer; property: "shots", type "sequence"; property: "state of condition", type "film-condition" (subtype of media-condition); property: OID, direct in "entity" (subtypes, "object", "abstract-entity"). )

*COUGH* UML as in OMG UML? as in prereq: MOF handling. probably dovetailing again with CXML, woo.

and I have to figure out which one of those to approach, first. and which one, then ... . Then, there's the dry stuff of cleaning-up the CommonLibrary codebase, merging it into tal-base and some other systems, then the CommonObject codebase, merging it into tal-clos-* systems. That, then, is some dry work, nonetheless requiring of my full attention. "Woo woo" I can still import split-string-1 into tal-base; no joy.

This gets published as-is; reader gets it as-is. The writer of this reads it without the HTML rendering; if it's broken, "kicks it for the HTML of it."

Representing the media of a roll of film is one thing, now.

This 'blog entry, in this draft, is another thing. It is a discrete, discerrnible thing. The contetnts of the thing, in each draft of the thing, may be subject to change. Any portion of the contents of the thing, if excerpted from the thing, is an excerpt of the original thing. (Would you happen as to notice, this may be made as to dovetail with digital rights management, if just for a reliable damned audit trail? Much may I enjoy to be able to determine, reliably, what was the original source of a quote I would be reading of a thing.)

As a person, I can discern if person M is person M. If my computer is configured to accept input only from M, that computer must be able to identify M -- upon a measure of authentication, reasonably binding.

So, there is a binding-strength, a quality of authentication. It is represented -- at a point -- systematically, in the level of "trust" affored to a GPG key -- "binding strength", as for the binding of a key to an identity.

"Binding strength" is affected across every point at which a thing may be reached. As soon as I produce a GPG key, for identifying my own with, that key is recognizable, to me, as it having an absolute "binding strength", onto my identity. A medium onto which the private compliment of that key would be stored, then the host by which that medium would be accessible -- let alone, the "security" of the actual device onto which the information of the key is or would be written -- that will serve to affect the "binding strenth" of my key to my identity. The "trustworthiness" of every item of software that would be let to access the private complement in that key, it also affects the binding strength of that key onto my identity.

There is no point at which I can accept a systematically absolute measure of that key's bidning strength. Every determination that I may make about its binding strenth is wholly subjective; the only way I could assure, absolutely, if it would not be? There is none! I have not psersonally overseen the development of any item of software or the production of any item of hardware that may access the thing -- naught of "any", none of "every". Every measure of "binding strength" is subjective. I cannot even trust -- to absolute, systematic accuracy -- as that the filesystem has properly recorded the information that the software generating the key had genreated; I know it as a trustworthy filesystem, and a trustworthy device -- this is not a measure of absolute, systematic accuracy.

Would I, then, endeavor as to represent "binding strenth" in a systematic manner? It is the user's responsbility to ensure that the user has adequately verified the integrity of what the user is using.

How, then, will I rely on any system, if I will not rely on a system that cannot verify, to 100% systmatic accuracy, what is the identity of a user? It is a spurious question, a device merely of a rhetoric discourse.

How, then, may I measure any percentage of the accuracy of a key-token's "binding strength", but that it is a subjective measurement?

Kerberos represents one means of authentication, requiring of transmission in regards to 'tokens', and not requiring of transmission to any more of applications.

At {EOF}, a basic roadmap to the tal-ident-oid system, leaving apart the parts that would have to be done (trivial stuff, largely, and requisite) directly for tal-ident-locator

resolve the OID-token to an object

"anchor" (register) the returned object as the "new" (or rather, "next", linked) end-point, in the assembly of an OID "arc" (This will not always be done after an OID-token_[N] is resolved. A remote peer may have requested that the token was resolved; that peer would have to take care of the anchoring, in its own environment)

produce an encoded form of an OID arc -- by what encoding? If it would be an arc with every node being resolved to a single, numeric value of a fixed, known width, that arc could be encoded as a representation of only the length of the sequence and the contents of the sequence. When via an ORB, then that 'node' may be represnted just as an OID node, leaving it to the ORB to handle every part of every node, and the protocol wrapping.

[N] a fixnum, generally, if not a bignum, if not a string. (If as a fixnum, then encoded as per what byte-order? GIOP may be recognized as supporting a negotiation (?) of byte-order.)

A topic map may be mapped onto a bibliographic reference system., "somehow". ("Do I know how?" It would be addressed in implementation.)

One may assert, People are uniprocess organisms. Yet by the assertion, one may likely question, How does the processing occur, within a person's own cognitive cortex?

If there is not determinable any one, single definition of architecture for the mechansm of our minds, so is it as much that the observer is, in the observation, that which is observed. Nay, it is not of a theory accreddited of and to herr Heisenburg. It is of a matter requiring a most circumspect consideration. We observe what is of ourselves. We are characters given to opinion. If our observations would be let to become warped on opinion, it is of and to our own failing.

A more subjective discourse follows.

Might it be, if the human mind does support a manner of multithreading &mdsah; whether or not we would be aware of the exact architecture for such?

Might it be said, Each person is the but operator of the one's own mind? Each person may also be the one's own administrator.

It seems, to me, my mind is not "just a system." It seems, to me, one person.

If I would represent a published work, representing it within a topic map, I would (or may, depending on how immediate would be the appearance of necessity) may prefer to represent the work, in such a manner that would .... would what?

would identify the thing according to a normal resource locator (i.e an ISBN, a LoC CCN, and/or a localized identifier, perhaps an OID representing the thing's availability within a database)[7]

would serve to identify the title of the work. If onto a normal bibliographic reference system, the title may be determined of the object to which the locator would be a reference.

would serve to aid the reader of a document presented on the identification, aiding the reader as to find the document, in form of printed and/or electronic media.

It will be to my own fault, if I will leave this thread ended here.

A moment ago, the thought had occurred: There is a difference beteen representing the information and representing what is represented within the information.

That may be as to lend segue to the statement: There is a difference between representing the topic map topic and association elements, and representing what is reprsented in those elements.

The topic-map serves to suggest an association of objects.

In how the objects represented in the association are constituted, it should be left neither to a filesystem nor to any one transport mechanism nor to any one database table or any other serialization system. It should be done within a normal object environment — at which, the reader may know if one would propose to utilize a Lisp image, on a Common Lisp architecture defined with full support for MOP, let alone how the OS-facing interface would be.

A topic map may serve in facilitating the representation of a human-visible interface onto an object system.

The structure of an outline is defined as seperate from the objects — the objects being those onto which the outline would represent a structure.

Certainly, it would be appropriate for an author of a document to present at least one structure, across the chapters of a work — as for the presentation of a logical flow and an organization of topics.

Consider, then, the dossier — a record about an entity, possibly containing references, references onto published works. When it would be a dossier about a person, those references may be made onto works by the person and works made as to be about the person. When it would be of an agency, the structure would be as "however" — something appropriate to an agency; one could denote known membership, and known participation with other agencies_[1], let alone known products, known product lines, known {what does one call the thing ... it would be associated to a "marketing drive"} .. i.e. known product platforms.

Inasmuch as I may determine of it: Symbolics existed, in a time before the corporation (as agency, if not as empire), was so grown.

That a coporation woud be established with international presence, and would appear with semblance of "(huge) clout", how may one say? "More's the making of their chessboard?" but of all of the board, the field, the members, and the supposed players to it, there might be more of the form to it, if one would so take the metaphor.

People, of our opinions, we may represent things as how we see fit. In the structuring, the definition and constitution of an object system, we must be — is it not? — objective. If one would not be duly objective, if one would not represent enough of the facts, as they most wholly are, and as they are wholly relevant to the material,_[2] if one would not, it_[3] would be just not good.

In how many words?

In a society whos government remains as democratic, no one citizen may be in charge of the government.

In a society whose government was architected as to be democratic — then of what is the most direct grievance? Resolution is addressed not but that it is addressed upon grounds.

Within a topic map, there may be represented a systematic identifier of a known entity — such as a committee of the House, a committee of the Senate, a one congressperson (if xml.{chamber}.gov would come up with a current registry of whom, and if not, then upon screen-scraping), a one region within a geopolitical body, or even a one species within a domain of natural study.

Topic maps may be used in the presentation and association of succinct references onto information systems.

Material addressed not to the Madison Project, but of such concern that might be addressed after the Madison Project follows — The Madison Project, to which a portion of the Tioga Project may be used as a library. Other portions to the Tioga Project, conceivably, may be used in supporting devleopment of the Madison Project, and of other projects — hopefully, as if it's been done right, of "us?" (sure, in some terms of comprehensiveness and applicability measured upon inherently subjective grounds, and for no political bandwagon.)

This is put as with a note: Grievances long set may become to a festering anger. Grievances addressed — then to what, the address? A political fandango?! Frail waste! To consideration, "if nothing more!"

[1] (Content inclined to tweak a political nose follows) E.g. CIA X cooperating with Afghani Regional Uberlord Y. Shortly later, in Afghanistan, an opium trade blossoms. "Imagine".

(end of text in addressing a pecuniary topic)

[2] (Content potentially affecting a political impression follows) ... then one might care to determine if there is a most resolute grounds for impeachment. It must be most resolute, when for that it would be made to a House committee.

(end of text in addressing a pecuniary topic)

[3] (etc; "watchout, this gets rough!") ... it may serve to give a one — and his party — a chance to make fools of us all.

If one would endeavor, as in a normative manner, endeavoring to redress one's grievances, one may firstly have to enumerate one's grievances. Much may material become conjoined, when it is affecting directly upon emotional ETC[4].

(FIN)

[4] have you checked the latest casulty count, brother? ?

DefenseLINK News: San Quentin Inmates Join 'Operation Mom' to Support Troops

and the rest dovetails into politics

[5] contrasted to "the topic-map user-agent as a token to marketing drive" — as to such that one might expect not few of, in coincidence with XML_[7], marketng drives. One may find so many of such, it could leave a person soured on the technology -- if but when one would reside as observer about the matter, uninvolved, at the time.

Why the involvement? Why, as it appears to my own determination: CXML rocks. It also does well, at processing a nearly-one-megabyte bookmarks file, into DOM-structured representation.

To make use of all that information, -- of the information represented in those bookmarks -- an objective, presently shelved.

[6] The outline represented in the example contains exactly two nodes onto the source outline; it is, by far, and incomplete work.

I have wondered, at times, whether I should endeavor to represent the nodes to that outline, representing such within any sort of a formal object model. If I would, I think I should leave it as within an XTM model, for now. It is information represented not of an exacting, systematic character -- had not been produced so as to be as so, the titles to the systems categories represented in TR/69 (at that fact of it) -- and, I consider, it is important, the structure and definition of those sysetmatic categories. It is related to the Ecma's PCTE work, and may be taken as towards a general grounds -- as, it appears, it was intended to have range for.

I say, Hurrah to Ecma.

[7] If the "marketing" part of it leaves one gasping for air -- anoxic -- but yet, can one blame people for trying to make commercial headway about what would appear as it being a "new technology"? Let alone, when it is presented as something sensational -- oh, as "the final format of all formats!" (XML was supposed to be?) and as "the next big thing coming!"(when it was, and there is still momentum of it, no doubt) then, to an efffect, "Learn to program XML!" (a funny sounding statement, no? but it occurs, even while: XML is an information format. It is not a programming language. In XML, data and programmatic instructions may be represented. Then why would one do so, when there is the syntax and full form of the Common Lisp langauge? Not so many people know any detail of the Common Lisp programming langauge! and it is to a broad system, in implementation of the language, as into the production of something systematically and nicely, feasible, viable, applicable, "how many accurate words would you want for it?!".)

coming from someone with a certification in "XML programming", at ... what the heck it's called ... that online (non-SSL) "certs." site ... "braindaddy", or something. There is an apostorphe in the logo. It is not TechRepublic, but it was at about the time when I was paying closer attention to their site.

... EggCertifiedOnCom. something.

apparenty, it's become cognitively associated, to my recall, with NewEgg, but they are a hardware sales shop, and GoDaddy but they are a DNS registrar and certs place and furthermore, with a Viet Nam veteran as their CEO.

"Braindaddy", temporary label to the one agency, a "certifications" vendor of ago. They are probably still around.

Wednesday, August 16, 2006

world-wide shop class

A poem may be written in one line of words.

Sunday, August 13, 2006

Upon a Stalling Dive Before SGML

Upon taking a break from the material of a project, such that is, by this day, in a formative state of condition, I am now able to take a fresh look at it. I may address a question, now, of if, how, and why it would be worth it.

If? but it is.

How? That is what I am in a stall before — before being able to explain the evident how of it, to a public audience.

Why:

The baseline stuff, it is some stuff that I still need to get shuffled in from some libraries, such I'd been working on, over the past number of months. It should serve to be supportive of more projects to the Tioga project; it may be utilized within other systems, then, once it would be available in a public release.

Some time along, then, other systems should be feasible, as to be implemented in application of that code.

At some point, I may be able to found what I have come to call the Madison project. It could be fit for a distinct representation; I do not intend to make a short summary of it.

Of course, if I would not be ready to disclose the whole cause of why, that would be unfair. It is a matter of some organization of resources, and of some founding, management, and continuation of efforts, largely disjunct from software. The Madison project would be for an information system, supportive of the work. The work, as it is &mdah; in what I will take up, of it — it must be made in close attention to the UN ODC. (Why so strong as "must"? It stands to reason, though I will not even try to enumerate the reasons of it, here.)

Why, then?

There is cause for it. I have no doubt that the causes will be apparent, lucidly, on addressing the material about which my concern is ... one could say, is set to swell.

Are you aware that there is, in this day — and even may ("may", for I have not a final reference on it) be, in irrefutable fact, even in this American nation, so prided on what's the pride lobbied on — there remains real fact of human slavery. In what becomes of it, it must be among the most vile products of humanity.

Maybe that would serve to indicate why it is that I will not address the material of it, in any long word, here.

If this one web-log would be whatsoever like a drafting table — though disorgnaized in the form of it, to a property that is attendant beside the protocols used for to operate this "web log" — but I do intend for that a reader of this will not be met with account of such that may strike the heart to stunned, of the ill.

To my consideration, it occurs as it being a long-set goal, Project Madison.

That the systems to that project would be done as well as I am certain is required of it &mdsah; and it would be feasible, upon available systems — that is just a point of fact. Motivation for it, then, I might have a time determining any warm tone of, but there is motiviation for it.

Today, then, there has been remained no spot of code, available, of the Tioga Project._[1]

Truly, I must consider: The Tioga Project is not such that I may afford a way of life upon.

Again, I am approaching the end of my savings. That does happens, true, when there is fiscal expenditure and no fiscal income. To be comfortably along, on my work — I have never known the situation, in any plain, sustainable manner.

N_ was some ugliness; the wage was greater than I had realized I may find, of this city, and it was ugliness. My wages were as leavings in support of the ugliness — flatly systematic, my approach to it. After becoming certain that I should be done with it, then quitely, I resinged. I am glad to be gone from it.

Now, I am on the remainder of my savings. It's been some low going — my only conceivable point, to be continued with the projects before me. If I have given up on __, might I now come to realize it.

It is as so, I have given up on __. To my rational mind, can I not conceive that I may regain, that I would so much as recognize the j_ and the h_ remaining, to me, of __? I wonder if she knows how beautiful is her — so many things, one cannot put but some few words to, and expect that it would be to the expression of the real matter.

What is a hope to me, then, that I can do nothing upon? But by coincidence, that I may expect to meet her, and I have been in ragged form.

Not with a sense of abandon, may this be, but I will leave here.

Before I ill start the Madison project, I will need to have resolved a lot more material into the Tioga project.

It is not that I intend to forever hold off on it, then, why it is that it has not been done. I do have a substantial portion of code, available for it, already. There is, that I have had my attention set on other material to the project. I am aware that it will take some time, and some generally bothersome trial-and-error, to resolve my existing code into the Tioga archives. That hill, the effort of it, I have not been settled as to take — and would you know, how it is to take a mountain? Under no fire of weaponry, it was a mountain by Lake Edison; I will not say the more of it..

Presently, I have to work out an implementation for what may be the most awkward system to the root project. That awkward ball of work, then, it is supposed to be: Something that should be reasonably suportive (as if!) of integration (of what? by what?! hacking!) across SGML documents to the project. I am perturbed that I cannot write a speck of CL code for getting it done; to even try to make a utility for it, as in Common Lisp, it may be superfluous, beside the SGML hackery.

So, I will have to leave it for later. I may hate that I would have to — I can spot the cause for it, now, and I am not sure how well I will be able to articulate it, if the prhase "cross referencing" would not be enough to indicate the matter by, then the diversity of documents, and that I must ensure that if they are diverse, but they must be not diversely structured.

It is SGML that I use for the documentation that I have written, thus far, to the project -- so far, just some few reference pages, with cross-reference links that do not work, as now, and I am aware of this.

Why SGML? It is SGML made with the DocBook DTD.

It is the body of DocBook Modular DSSSL stylesheets, such that i intend to apply in the system for producing HTML, output on the documentation. Though I have dreamt it would be feasible, but at trying to run a DSSSL engine on even a valid XML document, I have encountered a clear hassle of the software, in such that I cannot so much as try to resolve. It must be SGML.

If on a moment of null patience, I might find a sense of anger, then, at how much of a mess has been made, let alone of any body of documents, but across the progression from SGML, to XML, and then to 1001 XML bandwagons. I could be glad to be done with it — filter it through the Common Lisp REPL, and be done with tlike so — so, inasmuch as I would encounter. DocBook SGML remains as the most viable format for my to produce any documentation by.

I could be tired of that it is so, but it is as so.

In point of relation, for cause of fairness: I would like to continue to work with DocBook — not as it being a DTD, and not as it being all definitive of the structure to a document, and not if I would have to apply DSSSL or XSL to produce anything that a reader may view, of it. There is a lot of material to DocBook; upon a measure of familiarity with it, one might observe that material, then take the observation as toward the design of a less constrained, less awkward system, but nonetheless applicable, as for the markup of text and the production of documents.

Why, then? "Because that it may be done" is no more enough.

A form recognized upon intellection — perhaps, a form founded on a candid observation of reality — it cannot move the heart. It is of the heart, of whence a person's motive is drawn, is it not? I can fathom no other grounds to cause.

To be on with it

But on with which, then? There may be some numerous "to do" items, on a one person's desk.

[Update, same evening]

Maybe here's been a crux about why I get bothered about trying to work something onto SGML: I cannot make the reference for it — and neither may I make the implementation of it — anywhere nearly as succinct as may be made in an implemenation of some Common Lisp software.

If I would observe a portion of an hack on SGML, I may find it implausible, then, as that I would understand how that hack is supposed to be applied.

("cough". conventional hacking is, still, conventional hacking. That is the full form of it, involving of some conventions, onto a decided approach about hacking. Hacking conventionally — may it sound any more comfortable, in converse?)

Why, then would, one endeavor as to hack? (I know, there may appear casue for it; I intend to raise a question of why it would be.)

"Hacking" might appear to constitute a fairly uninvolved behavior. One might be either intimidated about or not aware of much detail about what one would be endearoving to hack about.

I am aware that the term "hacker" may bear some quaint connotations, to some. Contrasting it with the term, engineer perhaps a concern about the matter might become apparent. Hacking may sound like an endeavor somehow carelesss.

The words Hack and ad-hoc do share some consonants, and some vowels, and some intonations. In some of the worst connotations, a hack may appare to be a clumsy, fragile, and inelegant -- possibly, broken -- piece of work.

Yet, there may appear a necessity for that a system would be hacked upon, so as that it may be used, while under some terms of partial adaptation.

{yaddadah yaddadah} design, in implementation

yadunno, maybe: Right at now, I have something else to finish out, other than to write out a full explanation, here. Sure, this is a web-log.

[1] By this time, I have checked-in some material to the admin tree, for it. I've not published a reference to that source tree. t could seem to be to no great point, quite, to publish a URL to the tree, when there is nothing publicly available, today, no available, exectuable source code, to the project.

Saturday, August 12, 2006

By How Many Definitions, SCCM?

Some variations on expansion to the acronym, SCCM, indexed per place of evidence.

standard cubic centimeters per minute

software configuration control manager

System Center Configuration Manager

Special Crudpuppy Cola Mortgage (homage to software configuration and change management

A peculiar nonsense page: Get Rolex Submariner Online Now? Rolex Submariner at rock bottom prices!

One might observe how they have contrived the host-name on that URL -- trivial thing, probably demonstrative of not much, but for what may have been an observation of behavior, viz a viz that host names have been defined by network managers, then taken up to a non-understanding.

One might wonder what semblance of logic their system is operated on.

Friday, August 11, 2006

Onto The Tioga Source-Localization Mirrors

This was started as an informal draft for a document to be produced in addressing an administrative concern in regards to the Tioga project. The concern occurs from an administrative perspective, and from a developer's perspective ;it will stand to affect development on the Tioga project.

For that a matter may make it easier for developers on the project to develop (as voluntarily) material of the project, I may be willing to take up some more of administrative burden. Furthermore, when I am proceeding as developer on the project, it may make it much easier, for myself, if a given item of work would be done on the administrative side.

Upon consideration of the matter, and while my hopes had been up for that it would be an easy thing to implement, but now it appears as that it would be nothing distinctly clean to implement, a series of Arch-maintained mirrors to non-Arch-maintained codebases, for such codebases that would be applied in direct coincidence with systems in components to the Tioga project.

It appears that it will be easier for me to use all of the shell-commands that the mirroring will require, and to do so, manually, rather than to implement a suitable architecture and model for how it would be at-least controlled from within a Lisp image.

Regardless, the following may stand as a body of notes, towards the design of such an architecture.

The matter: In regards to this graph of systems that I am aware of, and which i have been yet unable to publish (and wll probably revise, before it will be set into any manner of figurative concrete) "this", a design draft for the full structure of some primary projects (all marked as proposed, at this stage) to the Tioga project, then in regards to the systems mapped out in that graph, a number of those systems will be depending on code not produced in the Tioga project.

I am not aware of any single source-localized project (?) utilized by the Tioga project, and such that would be using TLA, today. I know of one using CVS. I know that there is at least one using Darcs.

The Tioga Project will beusing TLA. Why? TLA is reliable; I'm familiar with TLA, and I'm the chief guy on this project. TLA is well done; that is not to suggest as if other SCCM systems were not, but I can speak of TLA, which I am familiar with.

There are means for making a TLA archive to be compatible with other-type archives. In one tla-tools (?) package, in Debian, there is a script for keeping CVS a archive (eh, 'module', rather?) synchronized (whether bidirectionally or unidirectionally) with an Arc archive. Additionally, there exists code for importing a Darcs checkout into a TLA archive, with some special handling about properties w.r.t Darcs.

At this point, I may begin to feel, somehow, small. It is not as if that was a directly voluntary effect, but it is occurring.

Why is that occurring?

It is occurring upon consideration of what I had addressed, earlier in this evening (this early morning, when it is dark outside, and substantially like "evening", to someone well familiar with a graveyard shift), material in regards to TLA archives, and the modeling of such, and operations on such, and managing such, onto other SCCM systems.

TIDE SCCM is the component, such that that the multi-SCCM library will be addressed onto. (The "T" stands for "Tioga", and the rest of the leters, I am certain one may know the expansion for.)

I will not have the luxury of representing the initial design of it, into UML.

An operational protocol onto SCCM systems, I might have to take responsibility to define. If it will be feasible, in a sane manner,, to make an in-library compatability layer between SCCM systems, then if I am to represent the matter as well as I should require of myself, it should be addressed into the TIDE SCCM component.

How wlll the design be substantiated?

"Who is a master of SCCM?" I mean, there is no Masters in SCCM credential that I am aware of. So, I may take it that we are all pretty-much on a level ground, there — some persons, then, some persons having (variably) more experience about some approaches than have had some others.

Proposal one, M of N:

retrieve version-designator destination

(no)

If that would be a naive function, but it appears that it may serve to accomplish a desired end.

"Retrieve" might not be a great name for it. The destination may be located not on the host on which the command would be executed. "Transport" might appear as it being too general, in a singular name for a function. "Deliver", I like the sound of; that may have something to do with some time as a pizza delivery driver.

The deliver function (hey, it works, the name) may be applied so as to ensure the transport of a value_[1] from a source to a destination.

[1] value — I cannot try to eek in a word more suitable to the matter, or may I? I like the term, value. I like the push-mode approach of the context in which the term is applied.

That the term value may be applied as to denote something entailing a number of files, such as a tape archive or a body of files to a codebase would, that application of the term might seem to stretch the concept of a value, in how the term may be applied in literature about the Common Lisp language. There appears to me no incompatabiity about the concepts — it is of a discrete portion of electronic information, even that which is not immediately available in the same process and may be not immediately available on the same host as that in which a command operating upon such a value would be executed.

One could say object. and that might seem to lend some ambiguity about what is being transported. In the deliver operation, what is delivered may be not information representative of properties to the designator object, but rather, information of which the designator object is representative.

Proposal two, M of N:

deliver source-designator destination-designator

(still too naive; not reprsentative of such modality as one must represent for an archive-affecting/source-tree-affecting operaiton)

That function should be defined with the argument precedence order (source-designator destination-designator), considering that the behaviors of destination, per source would vary less than behaviors of source, per destination. or something. maybe.

Tangential point: A system operating to deliver a designated object may have to serve as something of a proxy, in order to retrieve the information, using one protocol, then to make the information to the destination, using another protocol. To operate as so, the system would have to support the protocols for the source and destination, and would have to have a means, defined internally, for transporting information from one to the other.

On further consideration: that trivial deliver function will not be enough to truly represent the type of operations that may be executed, as beteen an Arch client and an Arch archive.

I am not fully familiar with the TLA commands — it should be easy to reference, at some point — but I think I recall all of the following:

something like the DARCS 'get' (archive-to-client), such that might be represented with one of the following, in reasonable generality

TLA 'update' (archive-to-client)

TLA 'replay' (archive-to-client)

TLA 'import' (client-to-archive)

TLA 'checkin' (?) (client-to-archive)

In an operation for a delivery of a body of changeset information to or from a TLA archive, there must be represented a sense of modality

Maybe I will have to scrap the trivial deliver function?

Each potential representative of TLA command wll require a distinct funtional syntax, for it to operate.

The tla help documentation is rather well structured. Following is the top of the outline produced of it.

Help

User Commands

Project Tree Commands

Project Tree Inventory Commands

Patch Set Commands

Archive Transaction Commands

Archive Commands

Patch Log Commands

Multi-project Configuration Commands

Commands for Branching and Merging

Local Cache Commands

Revision Library Commands

Published Revisions Commands (NB: regarding grab files, the member)

Miscellaneous Scripting Support

(formatting supported by Emacs regular-expression-driven text-replacement commands)

(With all commands listed, that listing may appear, to a new user, overwhelming. At my last count, there were exactly 100 (or 101) individual tla commands. It is a full featured SCCM system, to be sure. Once one would be familiar with the oeprations of it, and would have all of the simple configuration stuff taken care of, then it's pretty well managable, to use TLA, via XTLA or XETLA. There are, in addition, a number of support scripts, for accomplishing some common operations on TLA archives, and accomplishing those in batch mode.)

Some of the commands, identified in in the full commands listing, may be supported with application onto CLIM panes — for instance, commands productive of logging output, and of values identifying ny properties of a file (viz. the file's tagging ID, and the file's containing archive).

No, one function will not be enough for it.

The deliver function may still be defined, but would have to use one or another distinct, archive-accessing functions.

Archive user ID

(TO DO : Xref ECMA TR/69)

There may be defined an object representing the identity of the user, onto a TLA archive.

In operations directly onto a source-tree, such that would be used in conjunction with an Arch archive, a user's TLA archive ID may be used in the production of file archive IDs. There may be additional applications of the value.

In access to a TLA archive, an object representing a user's identity may be used for the facilitation of authentication by way of the SFTP (SSH) and HTTP (WebDAV or not) archive-access methods.

What I'd thought I would need to do, most promptly: To produce a mirror of a CVS archive, into a TLA archive, then to mirror that TLA archive into the Tioga project's archive space. (Is that not how it should be? I might prefer that the mirror would be made, firstly, into the archive on clnet, then mirrored to my own computer. It will be easier for me to handle the CVS-to-TLA mirroring on a computer that I can access, directly.)

Why would I do so?

so that a Tioga project developer may be able to use TLA on all projects pertaining directly to development of codebases originated of the Tioga project.

so that I might not have to direct my attention about more than one SCCM system, at the time of developing codebases to the Tioga project

However, I may have to be familiar with more than one SCCM system, so in order to even make the mirrors.

Ultimately, I might have to keep a distributor-type track on each Tioga-depended project, even for so much as to keep the projects' archives stably and contemporarily mirrored for access via TLA.

It must be feasible to do so, regardless of any doubt that may occur about it.

The task remains, now, to ensure that it would be done; that is primary to if I would try to produce a distinct expression of the rationale for it.

Apparent Menas for Mirroring a Darcs archive into a TLA archive, as via tla_load_dirs

(tla_load_dirs might be capable of handling not only Darcs archives as the input, there. By the manual page, it is not clear if it does or does not.)

This is going by the manual page for tla_load_dirs, such that appears to be descriptive enough to determine this by.

"check out" the Darcs archive into directory A

"check out" the TLA archive into directory B

cd B

tla_load_dirs [options] A

verify the new contents of B, if necessary

update the changelog for B, if necessary

within directory B, tla checkin or tla tag ...; tla update

I can maintain a table of projects, or of things analogous to projects, or of things analogous to codebses.

That appeared to be relevnat, a moment ago. The thought was budding, then was lost at some nyuck of sw stuff. and some more nyuck

1) one may represent a project's source archive, using a trivial x-sccm URI
2) how does one most officially establish a project's identity?
3) what would the records be used for?
4) to what extend would structure of relations among projects be represented? TIDE is administered of the Tioga project, and TIDE SCCM is contained of TIDE. One could represent those relations with some simplly structured relation classes, then shoved into a relations slot on an object representative of Tioga project — that approach may seem feasible, though not much appealing. I would rather that each distinct manner of relation would be represented as a slot value, not requiring a disjunct object.
5) Again, how would this be used?

I would like to be able to say "checkout archive for project A into directory B"

I might like to be able to say "what is the pathname for my local copy of the source archive for project A?"

Why
1) To be able to contain this (patience faltering, now) junk within one single director, under my home directory.
2) To map a single OID onto each and every distinct object-data thing (how: at one level, using TLA file inventory IDs)
3) [sic]

It is feasible, to create a non-user-specific value, designating an SCCM archive M, even when an access onto M will require a user-specific string.

A proposed syntax:

SCCM_URI ::= type ":" method ":" host ":" port ":" identity_part

identity_part ::= archive_path [":" name_path] [query_part]

query_part ::= "?" { keyname ["=" keyvalue] }*

The accepted syntax and acceptable values for every parameter-token after the "method" part will be specific to a given SCCM system.

(SCCM systems may share properties that may serve to support a sharing of code, in systems supporting the syntax -- e.g. using INET style host names, in the 'host' part; using INET style service names, in the "method" part.)

(In some situations, an SCCM URI may serve as to represent portions of a destructured URL.)

* The 'type' token

type : e.g. "tla", darcs", "cvs" (non case sensitive; conventionally, lower-cased; ASCII alphabetic)

** Registration of 'type' names

?

(May be assigned per the OID registry in the Tioga project - hm.)

"Well, I'll just make my own analogue of the IANA, right then, and ... (hiccup)"

type: e.g. "tla", darcs", "cvs" (non case sensitive; conventionally, lower-cased; ASCII alphabetic)

method : specific to the SCCM type
- tla : "sftp", "http", "https", or "file"
- darcs: "http", "https", or "file" (AFAIK)
- cvs : "pserver" or [sic]

host: specific to the SCCM type; conventionally, a DNS host name; may be irrelevant w.r.t a "file" method

port : specific to the SCCM type; generally, optional; conventionally, when specified: a TCP-IP port number; if not specified, should be derived on the "method"

archive_path : specific to the SCCM type; conventionally, an ASCII string

name_part ; specific to the SCCM; may be irrelevant in some contexts (e.g. Darcs); conventionally, an ASCII string

Not included in that syntax:

user : here is a clencher. The user will have to specify the user-name; the system may support that a user-name will be spedified, when the URI is registered

Lovin' this tedious coding

Of Identity and the Open Source Domain

The Open Source Initiative has, available, Marks and Logos, as well as some technical instructions, regarding applications of the matters.

They've a number of images, available, in varying formats and varying sizes, some with speciality for web and some with speciality for print. They've really gone out, to make it easy for the person who would seek to apply one of their logos.

In regards to a suggestion of how those marks and logos may be applied: OSI certified projects may use the 'OSI Certified' marks, and genuinely open source projects may use the 'Open Source' marks. The marks be used, then, on web sites, and emailed (HTML) press releases, and printed press releases, so as to support the identity of the matter — perhaps not so dryly, but the implication might be summarized as so: "This matter coincides with the open source domain of software and systems" (namely, then, when it would coincident with of a matter of open source software).

It's been as a tangent to my own main focus, now, but I'd noticed that it's so. Marking the matter, here, perhaps I will be the more likely to recall it, and perhaps the relation may have been of any substantive import.

I have some code that can do this:

(revision= (nth-value 4 (intern-tla-entity-designator
"foo@example.com--arch/cat--br--v1.0--patch-1"))
(nth-value 4 (intern-tla-entity-designator
"foo@example.com--arch/cat--br--v1.0--patch-1")))
;; => T

It's not available, as yet, the code that does that. If it was, I might reference it here.

I've been intending to work on that code, in order to make some earlier code to be available — there's some reorganization to take care of, and some code-publishing. Before any of that, I have to make sure I can conveniently fetch some archives into some local files.

"It's fun code, I promise." It's very short code. It's the code that was getting hanged up on the — shall I say issue — a matter that I was encountering, yesterday, an issue in some software, such that had an effect: That everything depending on the code in which the issue was appearing, it was impossible to proceed about. Circuitous, the epxression returned to a start of it: Among that code was the stuff that makes that item in that example work.

The code includes a rudimentary object model for the representation of TLA revision designators.

That the code can do as it does — serving as an object model, and inclusive of some simple string parsers, the lot of it operating for the representation of (TLA-specific) revision designators —, it is enough of a start toards a universal SCCM library onto Common Lisp.

That it's started in support of my favorite SCCM system, so it is. As I've seen it: TLA is greatly convenient, especially when interfaced via such as XETLA or XTLA (both of which are available via Debian) I'll admit that I have not made much use of some of TLA's more advanced features — as in support for branching and merging. I've trusted that one would not run into a hard time of it, when using TLA for merging one branch of code onto antoher.

Crypes, some things are hard to edit down to a solid statement.

I can define a generic function with a pattern like as so, then:

store-it thing location

Then, I can use a TLA archive designator as the thing and a pathname as the location; I've the code for parsing a TLA archive designator, already.

For that function to operate, there'd have to be a CL library onto TLA commands, or onto TLA archive operations. It would be easier to leave the TLA archive operations to be interfaced at by way of the shell-command interface. It would be more elegant, to access the filesystem, directly — and Tom Lord has posed the suggestiong that such it would be a reasonable approach. It would be requiring of more effort — but no, I cannot say "more effort", as I do not know how much effort would become invested upon the prior of those two manners of approach.

The shell-based interface would be, undoubtedly, more familiar to a TLA user than would a more original interface for representation of and operations on TLA archives in a Common Lisp environment. The latter may be represented, ultimately, in a manner as like the former. The latter would be involving of fewer hairy shell-command calls, or of none.

There have been a number of developments made, recently, in regards to the implementation of an SCCM system. CVS was an original; RCS was something like a part with it. There have been, later, some systems derived on CVS, and then there are Subversion, TLA and the fork Bazaar, and Darcs, and git/cogito. There is also Mercurial. There are some other SCCM systems, around; I know of the ones listed before.

I would not recommend that one would try, of a single effort, to represent all of those within a single environment. Onto a suitable architecture, any one of those mght be represented, at a point when someone would need to have that reprsentation available.

I would like to reprsent TLA, Darcs, and CVS archives, within a Common Lisp environment. I may represent TLA/Bazaar archives, already; they use the same syntax for archive designators. Why, then, would I want to do so?

I want to make it easier to get done what I'm starting to figure out that I will have to do, in order to make some selected codebases directly available to Tioga project developers — of whom I am the only, if but to start with, and I'm the chief admin and founder of the project.

Why do I want to do that, then? I want it to be as easy as possible, to get the code, given a range of diverse systems, each one being such that I intend to make as a dependancy of codebases in the Tioga project.

At the first of those, there is one that I had come to have heard of, last night, Closer to MOP. That is the one most recently occurring to my attention.

The more, I will have to make a more formal report on, in a release of some documentation for the Tioga project.

"This dry, dumb start-up work", it is not so dry and is not "dumb" — save in that it is of some particular qualities, such that I will not endeavor to produce, here, a listing of.

There is nothing much that I may show of it, besides some documentation. In true, I might rather just work with the code, but I am the administrator on the project. If I would fail to exact my duties as administrator, I may expect that there will become a failure of the project.

Sometimes, it may appear that some converstation would be meet, in some company. Presently, I could enjoy a reasonable time apart from these considerations, and that my attention would be involved onto something not so thoroughly dry.

I know of no place in Fresno where there is conversation at 00:14 PDT. I know of no place in Fresno, where there is conversation that I have expected that I may become involved in, at any other time of the day.

This hangup, here, it is not rarely recurring.

To learn how Darcs archive identifiers are formatted — TLA, I can support, CVS, I am familiar with, and Darcs is a present third to this effective triad — well, that could be just about enough.

Indeed, that could be just about enough. To start trying to design anything, here, it would be out of place.

Road in a mountain pass

Tuesday, January 02, 2007

Friday, August 18, 2006

Thursday, August 17, 2006

Wednesday, August 16, 2006

Sunday, August 13, 2006

Saturday, August 12, 2006

Friday, August 11, 2006

About Me

Links

Previous Posts

Archives