StartingPoint RecentChanges

WhyPica

Difference between revision 4 and current revision

No diff available.

What needs will PICA meet?

PICA attacks the problems of


Anecdote from LionKimbro

Okay, so we found those groups, and it was good. By working on SubPathetaEdit, we collected all (as far as I know) of the energy into rewrites. At least we all know each other- at the very least. CoEd?, as far as I know, (@DATE@), is the one holding the torch. crschmidt and Eloquence abandoned their work, I think the LEO guys are still working, but within Leo, and I think CoEd? is holding it right now; that's thecrypto. If you want details on this subject, talk with me, or one of them, we'll fill you in on the details. I like Palimpsest, I think that's the way to go.

Other story: General Text Filter.

I looked around. Didn't find anything. I thought, "DAMN! This is a great idea!" I'm shocked that there isn't anything! Looked all over the place, didn't find it. It costs so little to make. I just went ahead and started doing it.

And then, I found XmlRpcFilteringPipe?! I told everybody, with lots of excitement! Holy Shit! There's one already! And what's more, it had 2 plugins for it already! That is, a Movable Type plugin, and a Bloxsom plugin. What's more, it already worked with Twiki's, because it was implemented in Twiki. (Or at least, it was; I don't know if it is now.)

We had to do a little work improving the plugins, they weren't totally up to spec, and they had hard-coded links to URLS, but we fixed them up, and promoted the standard. It was only like 4 lines of code to adapt my existing code to the discovered format, and I did so. Piece of cake, and now, we have a bunch of plugins and working servers. It's wonderful.

It was really surprising, because our respective specs were near-identical. The only difference, was I had thought to put in a self-documentation system, and Les had thought to put in a content type. I dumped the doc system, and incorporated the content type. Wonderful. It just works.

Now, we are in the process of making an HTTP Post mechanism, instead of XML-RPC. There is only one delimma left, and I think I'm going to just take the lead, say, "It's this way," and start implementing. Nobody really cares about which way the decision goes, it's kind of dumb to be hung up on it. I think everyone just wants to see it go forward now.

I keep thinking, "This should all have been done at least 2 years ago." Why didn't it happen? Because there was nothing like PICA. It's just haphazard, "here's an idea, does anybody like it?" And of course, the response is: "no," or utter silence. I'm sorry, that's just the way of things. That's just how people respond to stuff. Like everyone's got a veto card. There's no use in hating it, or dislike it, you just have to find ways around. Otherwise, nobody will implement anything anywhere. Sad fact.

Aren't there already lots of standards organizations?

Consider:

None of these fit our niche, for various reason.

There are "pro" efforts in our space. They hate each other. They scare me. They are not Pro-Am, they do not like the phrase "Pro-Am," they don't want to be anywhere near us.

As Lion said: " They are viciously fighting against each other. I mean, have you seen it? It's positively bloody. I was walking by Dave Winer the other day, and it was like: BLAM! BLAM! BLAM! CZ-75. Guts everywhere! Absolutely disgusting; Horrible. Trust me: You don't want to go there.

Part of the reason I am encouraging things like the efforts of artists and manifesto writers, is to keep it lighthearted, and friendly, and joyous. Things like that. "

More on why not just IETF

I think that the IETF process is way too big, and way too formal, for our immediate purposes. Once we have some solid stuff, and it's implemented and people have seen it, and even people outside PICA implement it, then we can start talking IETF standardization. I'm astonished that ATOM made it! I think that means that IETF consideration, and eventual approval, is a reasonable thing to expect.

OK, but if you want a more open forum, there are plenty of wikis and bulletin boards already, aren't there?

Sure, and while each of these might have a one or two specification discussion on them, none of them are focused on formalizing and providing exposure for new specifications of all sorts. See "what needs will PICA meet?" and "What functions will PICA provide?", above.

Well, what about ConsortiumInfo ? It claims to be "the source for standard-setting news and information" and hosts "the" standards blog.

As far as I can tell, ConsortiumInfo? only provides exposure for new specifications after they have already been formalized and voted on. PICA helps people interested in developing a new standard to find each other, create a first rough draft, and improve the standard before it comes to a vote.

Why amateur radio needs PICA

"Towards a Next Generation Amateur Radio Network" by Samuel A. Falvo II, KC5TJA/6 2005

commercial ISPs are unwilling to more secure and better-architected alternatives, fearing lack of adoption, and therefore irretrievable loss of research revenue. ... All of these issues presents a unique opportunity for the Amateur Radio service as a whole: to arrive at a next generation internetwork ... The amateur community has no equivalent to the ITU or IETF, yet it needs one badly, especially with all the technical innovation occurring with HF digital modes ... ... an independent Amateur Radio standards body that concentrates solely on documenting the various interfaces and modes that we use ... it is of utmost importance for NgARN to have a central repository of standards that can be openly searched through and discussed, with support for creating new standards as required. ... I now retain a local copy because I do not want to waste that much time looking for what should be commonly available knowledge... 'standards' can usually be pieced together after a few hours of scouring the web for the little bits and pieces countained on websites scattered throughout the Internet. Still, that's a few hours I'd rather spend reading a formal specification, not chasing dead-ends. ... I lean more towards following the IETF-style standards track process ... For a good overview of IETF's process and the problems it is currently facing today, see [2]_. ... ...

yet another anecdote

"It's very hard to find people to give feedback about a format being designed. So designers are pretty much on their own at guessing what might be needed by the users of the format. Once it is in use, more people look at it and give feedback when changing things is harder. Both situations are obviously frustrating." -- http://sourceforge.net/projects/lzmautils/forums/forum/708858/topic/3963219