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 vers
Jakub --
I agree with your concerns about clarity here, and I will rework
the doc and send out a new version.
Also, I'm not a math guy, but I have a feeling that you are correct
that "infinite" is definitely not equal to 10. Or even 10 * N_LINKS.
I think maybe I could choose a more appropriate
[
https://issues.apache.org/jira/browse/PROTON-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Pierce resolved PROTON-227.
-
Resolution: Fixed
Fix Version/s: 0.5
> Ruby bindings need a Data class
>
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 keep
On Tue, Feb 26, 2013 at 8:02 AM, Alan Conway wrote:
> 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 b
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
nat
On Tue, 2013-02-26 at 10:37 -0500, Michael Goulish wrote:
> Phil --
>
> Wow, I was thinking of using ASCII.
Markdown is 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
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 a
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
O
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 either (at least they do have a
branch, but the current release doesn't have a branch either).
Regards,
Rajith
On Mon, Feb 25, 2013 at 4:05 PM, Ra
+1 we should have a tag in the repo for each of our releases
-- Rob
On 26 February 2013 20:34, Rajith Attapattu 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 either (at least t
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
> o
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:
https
+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 distri
19 matches
Mail list logo