ComponentSystem

This is a messy page, and you should feel free to nuke it and replace it with orderly text.

Feel totally ok w ignoring this page.

Discussion

Sorry, this is another "techie" post, and what's worse: It's rambling. But here goes.

We would ideally be able to say, while working on a medium: "Create a log for each of these things. Expose the log by this URL, and make it visible in these spaces." If you could do all of that in about 3 minutes, and keep everything nice and organized- that would be amazing. It is also possible: It is a matter of designing software fictions that give you the language to express it.

There are many software projects that seek to do just this: They make a freaking huge enormous framework that seeks to do it all. There are a few problems with this, though:

  • It's usually pretty crufty, because it's got to write so much in such a short period of time.
  • It's usually very carefully administered, in a pyramid hierarchy, because of the way change can ripple out and break things. That means it advances very slowly, beyond the core designers.
  • Developers who invest themselves in the architecture become limited to the architecture. They can only (then) use the architecture, and see the architecture. Anything else is hard to look at, and the developer is almost powerless outside of the architecture. Not because of unwillingness, but because it takes so amazingly long to learn the architecture: This big, enormous, crufty, ugly, architecture. And while some essential ideas are transferable, most of the work is in the non-transferable stuff. Developers know this, and it scares them. So they end up not using the big enormous crufty ugly architecture.

With good component systems, we can learn the highways, and not individual towns. If we can learn the highways, then there are lots of different towns to visit. If you don't like a particular town, you can use your own.

At any rate.

Web software. Software for making things that work with the Internet. Mediums, for use by many people.

The main thing about the component framework is installation and configuration. You need to be able to automatically install, publish, discover, communicate with, other services.

Ideally, we'd like to be able to automatically load share. I write a program, and it is automatically replicated on AlexSchroeder's servers, JonathanRoes's servers, etc., etc.,. Should one go down, there's roll-over. If one computer's busy, traffic goes to the others.

But, I digress- let's go back to just making it easy to install a program on my computer.

The program needs to hook in with the server, it needs to have appropriate permissions, it needs a place to store data, it needs to find other programs that might want to make use of it's capabilities, it needs to say what it can do, it needs to publish it's APIs and resource consumption. If the veiwers on a website are going to see it, it needs to be able to be automatically themed like the rest of the site, likely through CSS or some kind of templating agency. There are also change registrations and notifications; If something happens, it needs to inform interested software, and if something happens elsewhere that it needs to know about, it needs to be able to set watches over there. There are, truly, a million thigs that need to happen.

This all suggests SOAP, WSDL, WDDI, or some other equivalents.

Is it reasonable that communication on the local computer should work over SOAP and XML-RPC and what not? I think it's certainly plausible. Most of the exchanges can be done through those channels. If they need more bandwidth, then you can work out-of-band. But the problem is exposure: if you have all this setup and initialization and configuration going over the TCP ports system, you've got a security risk. You could firewall, but that seems like a band-aid. It seems like you're going t

Meh… I'm rambling.

This page is disorderly because my thoughts are disorderly.

I have a bundle of things that I know are true, but I have not discovered the relevant ordering to them.

A glance at the computer industry tells me that it feels the same way: We know these things are true; We just have difficulty articulating them in PlainTalk, or even ComplexPlainTalk. This may just be one of those areas where you just have to shove shove shove and it comes out all right on the other end.

Here's one I'd really like:

  • A log system.
  • Automatically makes RSS feeds available.
  • Also can publish very simple HTML web pages.
  • Available by the blogger API.

Is this a blog?

No, it's a simple logging system for an application.

The idea is that you should be able to take a logging system, and easily attach it to your app. Use the blogger API (or whatever) to keep notes on things that happen.

If you want to see what people are doing with your app, just plug into it's RSS output. Or, hit it's webpage.

The goal, though, is that the cost of integration gets to be low enough, where it's actually worthwhile to do this.

Right now, today, it's cheaper to just rewrite this guy by hand, every time.

With sufficient architecture, though, it'll become cheaper to just install and use a particular logger, in a language-neutral, operating-system-neutral, whatever-neutral, way.

I vote, just call it a blog :) ApplicationBlog?, ProgramBlog?, ProgramWebLog?, ProgramLog?, AppLog? ?

Anyway, it may be easier to explain this in terms of having a program writing and publishing it's own blog, and reading other applogs to see what's going on. Strong metaphors catch on easier.

Define external redirect: AppLog ProgramBlog ProgramWebLog ProgramLog ApplicationBlog

Languages: