Email excerpts to claarify Prowl

[els]

First of all, thanks for trying to mobilize some momentum for
openmoney.

A quick clarification on the 'response formats': I meant that an
application would try to conform to the interface specs for response
grammar or syntax, but the response may still be requested or embodied
as xml, json, url-encoded or even plain text Content-Type. But this
issue is obviously not a deal-breaker, it's just a matter of expecting
applications to have the ability to respond in different content-
types.

As far as collaboration is concerned, a bigger issue for me is this:
could openmoney really accommodate my particular design requirements?
I wouldn't mind sacrificing some efficiency in favor of satisfying
evolving conventions, but I am very vigilant in maintaining currency
design integrity. I'm sure Michael is also, and that's why he cuts
right to the chase in dismissing suggestions that violates or
compromises the core principles behind openmoney.

Could you view the attached diagram and let me know if you or anyone
in the openmoney core group has seen the design implications of having
participants organized under currency brands as opposed to
communities? Essentially, if inter-domain trades is always going to be
an afterthought in openmoney, then collaboration between us might be
more disruptive than helpful.

I'd be surprised if we did end up collaborating, but if we did, my
preference is to have running code factor heavily in discussions. It
will force participants to really think through suggestions, like
allowing an unbounded proliferation of transaction grammar variations
or using site-specific naming conventions.

Whatever happens, we could always follow each others progress - you
know where I post my updates. My next posts will touch on a very high-
level architectural view of currency design, from problem definition
to marketing. Even though my ideas might not resonate with the
standard om viewpoint, the topic might relate to future om foundation
agenda.

...

It's been a while since we last had contact in January about Prowl and
microformats. After taking a long break from personal projects, I was
recently going through some blogs and came across your posts in
lebleu.org.

If you are interested, I would like to see more details of what you
have in mind as far as the interface design is concerned, maybe not so
much about the om foundation yet. As I understand it, you are leaving
flexibility in the response formats of the API, an approach that I
agree with. As far as requesting currency services, I am looking into
using HTTP header based parameters and status codes as much as
possible, which I'm planning for the next revision of Prowl. Will that
be similar to the om approach? I am also very interested in SMS-
initiated queries or service requests.

If you don't think there will be a good fit between om and Prowl, that
is also okay. I am mostly trying to learn as I go and feel my way
around, and I know there are cc proponents that are much more
experienced in programming, systems and network architecture than I
am. Whatever creates progress in currency design works for me.

Edgar