Alex Kotenko [ARCHIVE] on Nostr: đź“… Original date posted:2014-07-01 đź“ť Original message:Hmm, r1, r2 etc is ...
đź“… Original date posted:2014-07-01
đź“ť Original message:Hmm, r1, r2 etc is actually interesting. It takes less chars then array
(yes, array brackets have to be escaped) and provides unlimited number of
options, uniformed approach and priority definition. I'd say that is the
way to go. Any objections?
On 1 Jul 2014 16:39, "Andreas Schildbach" <andreas at schildbach.de> wrote:
> Ok, one more idea:
> r= is used for the first URL, and we *think* of it as r0=
> additional URLs are appended as
> r1=
> r2=
> and so on. This would also define an ordering in case we need it.
>
>
> On 07/01/2014 05:07 PM, Michael Wozniak wrote:
> > Multiple parameters is currently undefined as far as I can tell. Should
> the client take the first, last, or ignore it completely if there are
> multiple of any parameter? I think that’s the point of the parameter
> pollution discussion, which will define it one way or the other.
> >
> > I’m only familiar with the Electrum implementation, which is currently
> checking for any duplicate parameters and treating the entire URI as
> invalid if duplicate parameters exist (following the parameter pollution
> suggestions).
> >
> > -
> > Michael Wozniak
> >
> > On Jul 1, 2014, at 10:59 AM, Andreas Schildbach <andreas at schildbach.de>
> wrote:
> >
> >> Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
> >> advocate for a simple array parameter name, like rs= ("plural" of r).
> >> Length really does matter for QR codes.
> >>
> >> I'm fine with either multiple r= params or exactly one r= plus zero to
> >> many r[]= params. Although I think it is a violation of the (current)
> >> spec to choke on more than one r= parameters, I admit that bitcoinj is
> >> currently implemented that way. (We could however fix this in a
> >> maintenance release.)
> >>
> >> However, r= should also allow all other protocols, exactly like any of
> >> the r[]= params. I don't think we should do a distinction here. Also
> >> because of backwards compatibility to the status quo.
> >>
> >>
> >> On 07/01/2014 03:03 PM, Alex Kotenko wrote:
> >>> In my mind it's not like the client's phone is going all directions at
> >>> the same time. There should be a priority method and fallback
> method(s).
> >>> ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in
> the
> >>> end as always-working-default.
> >>>
> >>> ​So I'm keeping support for it all while want to be able to provide
> best
> >>> user experience.
> >>> Mike, a while ago in ​this thread you've described contactless cards
> >>> user experience. I'm also using contactless cards often, and what I'm
> >>> aiming at is creating same level of user experience for Bitcoin users.
> >>>
> >>> Encryption over bluetooth is a matter to worry about, and we will
> >>> introduce that, but we need to sort out more low level problems first
> >>> before coming into that stage.
> >>>
> >>>
> >>> So, the backwards compatibility is a good issue Michael pointed out.
> >>> While processing of multiple "r" parameters is indeed uncertain (since
> >>> there is no RFC for that various implementations may behave
> >>> differently), the array solution is somewhat better. The array
> parameter
> >>> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
> >>> alongside. And if particular implementation understands the array
> >>> construct - it will use it, otherwise it will ignore the "r%5B1%5D="
> and
> >>> use only usual "r=".
> >>>
> >>> This doens't work though for cases where particular implementation
> >>> understands array construct but doesn't work well with repeating
> >>> parameters, since it will see two repeating "r" - an array and a
> string.
> >>> I don't have a solution for that atm.
> >>>
> >>>
> >>> If add completely new parameter to solve this we will need to make it
> an
> >>> array straight away to address upcoming issues with accommodating other
> >>> protocols.
> >>> And then I would also modify existing BIP72 to strictly define "r=" as
> >>> "http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
> >>> Direct, ultrasound, chirp etc) should go to the new array parameter.
> >>>
> >>>
> >>> ​
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Open source business process management suite built on Java and Eclipse
> >>> Turn processes into business applications with Bonita BPM Community
> Edition
> >>> Quickly connect people, data, and systems into organized workflows
> >>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >>> http://p.sf.net/sfu/Bonitasoft
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Open source business process management suite built on Java and Eclipse
> >> Turn processes into business applications with Bonita BPM Community
> Edition
> >> Quickly connect people, data, and systems into organized workflows
> >> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >> http://p.sf.net/sfu/Bonitasoft
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
> Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140701/f3b7f78d/attachment.html>;
đź“ť Original message:Hmm, r1, r2 etc is actually interesting. It takes less chars then array
(yes, array brackets have to be escaped) and provides unlimited number of
options, uniformed approach and priority definition. I'd say that is the
way to go. Any objections?
On 1 Jul 2014 16:39, "Andreas Schildbach" <andreas at schildbach.de> wrote:
> Ok, one more idea:
> r= is used for the first URL, and we *think* of it as r0=
> additional URLs are appended as
> r1=
> r2=
> and so on. This would also define an ordering in case we need it.
>
>
> On 07/01/2014 05:07 PM, Michael Wozniak wrote:
> > Multiple parameters is currently undefined as far as I can tell. Should
> the client take the first, last, or ignore it completely if there are
> multiple of any parameter? I think that’s the point of the parameter
> pollution discussion, which will define it one way or the other.
> >
> > I’m only familiar with the Electrum implementation, which is currently
> checking for any duplicate parameters and treating the entire URI as
> invalid if duplicate parameters exist (following the parameter pollution
> suggestions).
> >
> > -
> > Michael Wozniak
> >
> > On Jul 1, 2014, at 10:59 AM, Andreas Schildbach <andreas at schildbach.de>
> wrote:
> >
> >> Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
> >> advocate for a simple array parameter name, like rs= ("plural" of r).
> >> Length really does matter for QR codes.
> >>
> >> I'm fine with either multiple r= params or exactly one r= plus zero to
> >> many r[]= params. Although I think it is a violation of the (current)
> >> spec to choke on more than one r= parameters, I admit that bitcoinj is
> >> currently implemented that way. (We could however fix this in a
> >> maintenance release.)
> >>
> >> However, r= should also allow all other protocols, exactly like any of
> >> the r[]= params. I don't think we should do a distinction here. Also
> >> because of backwards compatibility to the status quo.
> >>
> >>
> >> On 07/01/2014 03:03 PM, Alex Kotenko wrote:
> >>> In my mind it's not like the client's phone is going all directions at
> >>> the same time. There should be a priority method and fallback
> method(s).
> >>> ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in
> the
> >>> end as always-working-default.
> >>>
> >>> ​So I'm keeping support for it all while want to be able to provide
> best
> >>> user experience.
> >>> Mike, a while ago in ​this thread you've described contactless cards
> >>> user experience. I'm also using contactless cards often, and what I'm
> >>> aiming at is creating same level of user experience for Bitcoin users.
> >>>
> >>> Encryption over bluetooth is a matter to worry about, and we will
> >>> introduce that, but we need to sort out more low level problems first
> >>> before coming into that stage.
> >>>
> >>>
> >>> So, the backwards compatibility is a good issue Michael pointed out.
> >>> While processing of multiple "r" parameters is indeed uncertain (since
> >>> there is no RFC for that various implementations may behave
> >>> differently), the array solution is somewhat better. The array
> parameter
> >>> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
> >>> alongside. And if particular implementation understands the array
> >>> construct - it will use it, otherwise it will ignore the "r%5B1%5D="
> and
> >>> use only usual "r=".
> >>>
> >>> This doens't work though for cases where particular implementation
> >>> understands array construct but doesn't work well with repeating
> >>> parameters, since it will see two repeating "r" - an array and a
> string.
> >>> I don't have a solution for that atm.
> >>>
> >>>
> >>> If add completely new parameter to solve this we will need to make it
> an
> >>> array straight away to address upcoming issues with accommodating other
> >>> protocols.
> >>> And then I would also modify existing BIP72 to strictly define "r=" as
> >>> "http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
> >>> Direct, ultrasound, chirp etc) should go to the new array parameter.
> >>>
> >>>
> >>> ​
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Open source business process management suite built on Java and Eclipse
> >>> Turn processes into business applications with Bonita BPM Community
> Edition
> >>> Quickly connect people, data, and systems into organized workflows
> >>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >>> http://p.sf.net/sfu/Bonitasoft
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Open source business process management suite built on Java and Eclipse
> >> Turn processes into business applications with Bonita BPM Community
> Edition
> >> Quickly connect people, data, and systems into organized workflows
> >> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >> http://p.sf.net/sfu/Bonitasoft
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
> Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140701/f3b7f78d/attachment.html>;