BurningbirdRecovered from the Wayback Machine.
For hire:
Edgy, quick tempered, slightly manic technology architect/writer. Known to disagree with people on occasion. Can be somewhat opinionated.
Likes music. Orange.
For particulars, enquire within.
Recovered from the Wayback Machine.
Thanks to TX Meryl, I found this article describing web services in clear, comprehensible terms.
I like the article, but UDDI is NOT the approach to take for web services discovery. Not! Not! Not! Not!
Create a beautiful distributed technology, and then capture it and constrain it by a centralized discovery service operated by big companies. I don’t care if UDDI can be mirrored — that’s not the point!
Think about the technology Google uses to find all the information that we’ve become dependent on. Think about how well the company processes it and packages it and delivers it. I can find anything on the web, thanks to Google.
This exact same type of functionality can be used to discover web services if we implement a few (few, mind you) common specifications. We Don’t Need UDDI. The web of discovery will work for web services as it works for weblogging as it works for Google.
I will continue to beat you about the head on this issue until you ultimately bow to my superior knowledge on this subject 😉
Recovered from the Wayback Machine.
Dave is still talking about web versus C programming language. He mentions that scripting is what holds the web together.
Dave, someone has to write the base. You can’t create full applications with Javascript, without something taking the script and translating it into machine understandable bits. And that translation is accomplished through programming languages such as C.
As with proprietary and open source code, scripting and programming with a language such as C are not exclusive – they’re complimentary.
Now, if you’re saying that providing scripting capability gives people who aren’t programmers a chance to have a control over their content, I agree 100%. This is a win/win for both the scripting users and the professional developers — the former has more control over their environment, the latter can focus on the larger and more complex tasks we thrive on. And, yes, we have this increased flexibility due to the web … and to browsers that are enablers.
Perhaps Dave and I do agree on this issue but say things — or read things — differently.
Recovered from the Wayback Machine, orange color and all.
I like my new weblog color. Orange. Burnt orange to be exact. Bitter-sweet.
The color suits because I’ve found weblogging to be both bitter as well as sweet, luckily more of the latter than the former. But you can’t taste the sweet without the bitter, and sometimes a little of the downside creeps in to keep things in balance. Yin and Yang. Bitter and Sweet.
In my comments this morning I found a note from someone who says I lack credibility because in the last week I’ve pulled three postings regarding Dave Winer. The person has a point. We’ve tweaked Dave on this, and here I am doing the same thing.
I don’t particularly care that the person making the comment, “D” as he styles himself, doesn’t return. My readers must, at a minimum have a sense of humor. However, for those lonely few that remain, you are owed an explanation.
I pulled one posting to put into my technology experimental weblog because it had to do purely with technology, and I’m using this Alter Ego weblog for pure technology from this point. You can still see it there. It’s very civil, no burn, no rants and raves. I should have left a forwarding blurb — and the concept of that sounds both interesting and twisted.
I pulled a posting earlier in the week because it made reference to a posting Dave had also pulled, which was the result of an earlier posting I made which Dave took exception to. Did you follow that? You have to be able to follow some twisted threads within weblogging. It’s a requirement.
I pulled this posting for two reasons:
One reason is because it was flamebait and I’ve just not been in a mood to deal with flames this week. Yes, I can burn and bite with the best of them; but not all the time, and not this week.
The second reason was irony. I soundlessly pull a posting whose content was about Dave soundlessly pulling a posting. Try putting that on your scales and see if you don’t get jello. Call it weblogging’s first performance art and title it “Silence of the Postings”.
Finally, I pulled yesterday’s posting about the whole ugly Winerlog/Dave Winer thing. I was concerned that Winerlog was killed summarily, only to find out it was a web server performance thing. (And folks, if you haven’t noticed by now, all the editthispage.com web sites have lousy preformance — the server is maxed out.)
However, I didn’t pull the posting because I later found out Winerlog wasn’t killed out of hand (though this evetually happened last night). I pulled the posting because the whole thing seems so tawdry. And unnecessary. As Rogi pointed out so well in the comments — let Winerlog go to a new home and Userland reclaim their server space. End of story. I pulled the posting because I just didn’t want to waste more space on this issue.
But I am wasting blogspace today because D was right, I am lacking credibility for pulling the postings without note or notice, at least for two of them. And though we kiss the elusive D good-bye, I do care that those of you that remain are given an explanation. Whether you want it or not.
One last related note — Dave, no matter how ugly Winerlog gets, at least give him one week on your server to allow him to re-direct to his new weblog. And Winerlog, can’t you shut up one moment, long enough to get moved?
(Rogi, I hope you don’t mind me showing your comments out of context; I have the old comments, but not the old posting.)
Recovered from the Wayback Machine.
Dave is referencing his Full Peer again.
I like the concept of peers being able to link and serve as each other’s cloud. To me this is true distributed computing. However, a “peer” that’s guaranteed to be up 24 hours a day isn’t a true peer — it becomes a server.
For a P2P cloud, you’re going to have to a mechanism that can distribute services among a group of peers so that a request on the service can match to whatever is the closest peer that’s accessible. If you push the services out to one statically defined machine, you have client/server — even if you want to call the server a “full peer”.
Dynamic redirection of service requests. Dynamic installation of small, lightweight services on a group of peers. A store and forward functionality that allows a peer to signal it’s going offline, or coming online. That’s P2P. That’s true P2P. And that’s exciting stuff.