Re: [RFC] cgi value = 0 behaviour
I agree to this! If we should change the behavior I think we should add new fields to not break compatibility! / Stefan On Wed, 10 Apr 2002, Steve Rapaport wrote: > > >Or should I have new fields and deprecate these ones ? (like flash) > > That sounds like the best idea. The new field name (whatever you choose) > could be compatible with the DCS spec, the old one gets deprecated... > > -steve >
Re: [RFC] cgi value = 0 behaviour
Bruno David Simões Rodrigues wrote: > > On Wed, 2002-04-10 at 11:53, Stipe Tolj wrote: > > Bruno Rodrigues wrote: > > > > > > What do you think ? > > > > +0 from me. > > I guess I should RTFM ;) > > Clarify to us(me) what means the +0. (and other values) basically I have taken this from the Apache developer's mailing list. Where votes go like this: +1 = yeah, I like that, please go on +0 = hmmm, sound's reasonable, but I'm not into deep with that 0 = no opinion -0 = don't know exactly, but something is not the way it should be here -1 = I definitly dis-agree, because of foo bar. This way we can vote on certain issues more effectively on the list and all participating parties don't have to real long prologs about pros and cons of certain proposals. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [RFC] cgi value = 0 behaviour
>Or should I have new fields and deprecate these ones ? (like flash) That sounds like the best idea. The new field name (whatever you choose) could be compatible with the DCS spec, the old one gets deprecated... -steve
RE: [RFC] cgi value = 0 behaviour
On Wed, 2002-04-10 at 12:49, Andreas Fink wrote: > >On Wed, 2002-04-10 at 09:16, Oded Arbel wrote: > >> Me like :-) > >> > >> what this about coding ? I thought this is how it works now ? to send > >> unicode, I send coding=3. > > > >I meant coding=0 7bits, coding=1 8bits coding=2 ucs2 to match the dcs > >specs > > I would prefer > > coding=0 or missing means autodetect > coding=1 7 bit > coding=2 8 bit > coding=3 UCS2 > > that makes the interfaces consistent with olther releases. > otherwhise lots of people have to change their applications and in > kannel-kannel interworking you end up with a version incompatibility. Because unfortunatly the patches I've done doesn't make any sense now. "If you want a message class 0, set &mclass=1" : And we need to be able to set '0' values on cgi fields, like pid=0. The interface have to be broken someday to fix this, and I was only asking when should it be. between 1.1.6 and 1.2 ? or from 1.3 to 2.0 ? Or should I have new fields and deprecate these ones ? (like flash) > > > > -- > > Andreas Fink > Fink-Consulting > > -- > Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 > Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland > E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com > -- > Something urgent? Try http://www.smsrelay.com/ Nickname afink >
RE: [RFC] cgi value = 0 behaviour
>On Wed, 2002-04-10 at 09:16, Oded Arbel wrote: >> Me like :-) >> >> what this about coding ? I thought this is how it works now ? to send >> unicode, I send coding=3. > >I meant coding=0 7bits, coding=1 8bits coding=2 ucs2 to match the dcs >specs I would prefer coding=0 or missing means autodetect coding=1 7 bit coding=2 8 bit coding=3 UCS2 that makes the interfaces consistent with olther releases. otherwhise lots of people have to change their applications and in kannel-kannel interworking you end up with a version incompatibility. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: [RFC] cgi value = 0 behaviour
On Wed, 2002-04-10 at 11:53, Stipe Tolj wrote: > Bruno Rodrigues wrote: > > > > What do you think ? > > +0 from me. I guess I should RTFM ;) Clarify to us(me) what means the +0. (and other values) > > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Münsterstr. 248 > 40470 Düsseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > --- > wapme.net - wherever you are >
RE: [RFC] cgi value = 0 behaviour
On Wed, 2002-04-10 at 09:16, Oded Arbel wrote: > Me like :-) > > what this about coding ? I thought this is how it works now ? to send > unicode, I send coding=3. I meant coding=0 7bits, coding=1 8bits coding=2 ucs2 to match the dcs specs > > -- > Oded Arbel > m-Wise Inc. > [EMAIL PROTECTED] > > "Sick cultures show a complex of symptoms ... but a *dying* culture > invariably exhibits > personal rudeness. Bad manners. Loss of consideration for others in > minor matters. A loss > of politeness, of gentle manners, is more significant than is a riot." > -- Friday's boss > > > > -Original Message- > > From: Bruno Rodrigues [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 09, 2002 11:19 PM > > To: [EMAIL PROTECTED] > > Subject: [RFC] cgi value = 0 behaviour > > > > > > To enable smsbox to accept '0' values in cgi fields, the > > interface should > > change > > and the behaviour will be broken, but I think this should be > > done before we > > launch > > the new stable version (1.2). > > > > May I change the code and documentation now ? > > > > What will be changed is : > > > > mclass: instead of 0-4, will be 0-3 and -1 or not present for default > > > > pid: 0 really means 0 and -1 or not present means not present in pdu > > > > coding: 0-3 means 7bit, 8bit or ucs2 and -1 or not present > > means default > > behaviour of kannel defining it with udh presence > > > > compress: 0,1 forces no-compression (or decompression) or compression, > > and -1 means whatever (I haven't yet done the code to compression) > > > > validity: 0 means error (kannel can't send a message that > > already expired) > > and > > -1/not defined means smsc defaults > > > > deferred: 0 means now, -1 or not defined means now too ;) (or > > when kannel > > wants to send it?) > > > > alt-dcs: 0 means 0x0*, 1 means 0xF*, -1 means let kannel do > > what it wants > > > > So, it's only cgi fields introduced in 1.1.5++ versions. > > > > What do you think ? > > > > > > >
Re: [RFC] cgi value = 0 behaviour
Bruno Rodrigues wrote: > > What do you think ? +0 from me. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: [RFC] cgi value = 0 behaviour
Me like :-) what this about coding ? I thought this is how it works now ? to send unicode, I send coding=3. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] "Sick cultures show a complex of symptoms ... but a *dying* culture invariably exhibits personal rudeness. Bad manners. Loss of consideration for others in minor matters. A loss of politeness, of gentle manners, is more significant than is a riot." -- Friday's boss > -Original Message- > From: Bruno Rodrigues [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 09, 2002 11:19 PM > To: [EMAIL PROTECTED] > Subject: [RFC] cgi value = 0 behaviour > > > To enable smsbox to accept '0' values in cgi fields, the > interface should > change > and the behaviour will be broken, but I think this should be > done before we > launch > the new stable version (1.2). > > May I change the code and documentation now ? > > What will be changed is : > > mclass: instead of 0-4, will be 0-3 and -1 or not present for default > > pid: 0 really means 0 and -1 or not present means not present in pdu > > coding: 0-3 means 7bit, 8bit or ucs2 and -1 or not present > means default > behaviour of kannel defining it with udh presence > > compress: 0,1 forces no-compression (or decompression) or compression, > and -1 means whatever (I haven't yet done the code to compression) > > validity: 0 means error (kannel can't send a message that > already expired) > and > -1/not defined means smsc defaults > > deferred: 0 means now, -1 or not defined means now too ;) (or > when kannel > wants to send it?) > > alt-dcs: 0 means 0x0*, 1 means 0xF*, -1 means let kannel do > what it wants > > So, it's only cgi fields introduced in 1.1.5++ versions. > > What do you think ? > > >
[RFC] cgi value = 0 behaviour
To enable smsbox to accept '0' values in cgi fields, the interface should change and the behaviour will be broken, but I think this should be done before we launch the new stable version (1.2). May I change the code and documentation now ? What will be changed is : mclass: instead of 0-4, will be 0-3 and -1 or not present for default pid: 0 really means 0 and -1 or not present means not present in pdu coding: 0-3 means 7bit, 8bit or ucs2 and -1 or not present means default behaviour of kannel defining it with udh presence compress: 0,1 forces no-compression (or decompression) or compression, and -1 means whatever (I haven't yet done the code to compression) validity: 0 means error (kannel can't send a message that already expired) and -1/not defined means smsc defaults deferred: 0 means now, -1 or not defined means now too ;) (or when kannel wants to send it?) alt-dcs: 0 means 0x0*, 1 means 0xF*, -1 means let kannel do what it wants So, it's only cgi fields introduced in 1.1.5++ versions. What do you think ?
