Darryl L. Pierce created PROTON-251:
---
Summary: When adding elements to an array, elements of a different
type should cause an error
Key: PROTON-251
URL: https://issues.apache.org/jira/browse/PROTON-251
Jakub --
Thanks for your thoughts!
Yes, I am thinking of it as part of a larger doc, and yes I
definitely should change that to specify Proton Messenger API.
I keep forgetting that there are more quarks in this particle than
just the one I am looking at!I'll make that change in next
Phil --
Wow, I was thinking of using ASCII.
Let me look at Markdown hmm, I do like the sound of this:
radically simplified and far more human readable form of HTML
But what's the value proposition of using any kind of markup?
Better readability? Linking with other docs?
It seems
This is a good start! We should start a proton book so this has a place
to live. The Qpid books are in docbook under qpid/doc/book. I'm not a
huge fan of docbook but probably best to stick with it unless there's
something significantly better.
A few comments on the content:
On Fri, 2013-02-22 at
On Tue, 2013-02-26 at 01:56 +, Phil Harvey wrote:
I do agree with you that having documentation committed alongside code is
the right approach.
I propose that we write this documentation in Markdown syntax. That gives
us (or our users) the option of easily generating HTML whilst keeping
It's important that whatever it is adds minimal dependencies to the toolset
required to build. I took a quick look at markdown and it seems to have a
number of different implementations (perl, php, python, etc) that are
fairly widely available. The web site also claims that it is designed to be
One hole that I feel like I'm seeing in the messenger
interface concerns credit.
I have a way of using credit to set a max number of
messages that a recv call should return in one gulp,
or a way of doing ... something that I'm still figuring
out ... by setting credit=-1.
What I don't have is
Phil,
I think it's worth experimenting with an approach that has a low
barrier-to-entry.
Markdown seems very very appealing. Anytime you can get away with
plain text, it's great.
And as Alan mentioned, the source doc itself can be a finished product.
So my +1 for trying this.
Regards,
Rajith
+1 we should have a tag in the repo for each of our releases
-- Rob
On 26 February 2013 20:34, Rajith Attapattu rajit...@gmail.com wrote:
Rafi,
I don't want to sound pedantic, but we should tag our releases as per
the guidelines provided by Apache.
The previous releases don't have tags
On Tue, Feb 26, 2013 at 08:36:20PM +0100, Rob Godfrey wrote:
+1 we should have a tag in the repo for each of our releases
Definitely since, as package maintainer in Fedora, I need to then branch
from that in order to maintain patches on top of our official releases
easily.
--
Darryl L. Pierce,
Would it be possible, without breaking the messenger
paradigm very much, to provide some way of knowing
which messages had not been delivered after a specified
time?
i.e.
pn_message_set_ttl ( message, seconds );
and then maybe
int n_dead_letters = pn_messenger_expired ( messenger );
for (
Hi Mick
- Original Message -
One hole that I feel like I'm seeing in the messenger
interface concerns credit.
I have a way of using credit to set a max number of
messages that a recv call should return in one gulp,
or a way of doing ... something that I'm still figuring
out ...
On Mon, Feb 25, 2013 at 01:05:16PM -0800, Rafael Schloming wrote:
I've uploaded the artifacts and updated the download page[1]. It will be
about 24 hours or so until the mirrors are fully synced.
[1] http://qpid.apache.org/proton/download.html
Fedora packages are now released:
F17:
+1
This would make sense to me. It seems like it
1. does not break the messenger model
2. keeps the interface simple
3. allows more visibility in whether the messenger is falling behind
4. gives new capability -- throttling
5. still hides all fancy stuff about links credit
14 matches
Mail list logo
