On 03/13/07 16:26, Klaus Darilion wrote:

congratulations!

thanks for the hard work.

regards klaus

PS: someone should make a snapshot of http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel and name it pseudovariables:1.2.x and update openser.org/docs

openser.org/docs has to be updated, indeed, pseudovariables:1.2.x and others were done during the weekend. Thanks for reporting,

Cheers, Daniel

regards klaus

Daniel-Constantin Mierla wrote:

...

Hello,

version 1.2.0 of OpenSER has been released. It is major release, which means that you get along a lot of new features and improvements to existing ones in old versions. The configuration file and database structure suffered some changers, please read careful release notes to learn how to update.

Just to list few of the new features:

• SIMPLE Presence support

(http://openser.org/dokuwiki/doku.php/presence:presence-module)

• SNMP (http://openser.org/docs/modules/devel/snmpstats.html)
• PERL API (http://openser.org/docs/modules/devel/perl.html)
• JAVA SIP Servlet Application Server (http://wesip.eu)
• script variables and transformations

(http://openser.org/dokuwiki/doku.php/transformations:devel)

• DNS failover
• IP blacklists
• XMPP IM gateway
• XMLRPC
• SIP session timers
• secure federation peering
• retransmission timer accuracy
• usrloc refurbished for better performances
• automatic error handling
• AVPs in reply routes

Read full release notes at: http://www.openser.org/mos/view/OpenSER-v1.2.x-Release-Notes/

Source tarball can be downloaded from: http://www.openser.org/pub/openser/latest/src/ Or SourceForge: http://sourceforge.net/project/showfiles.php?group_id=139143&package_id=...

This is the first release coming out o SVN. Old CVS repository was migrated to SVN, and with these, a few changes apply to get sources from repository. Please read instructions from download page: http://www.openser.org/mos/view/Download/

Migration instructions (although not complete, I'm sure) are available at: http://openser.org/dokuwiki/doku.php/install:1.1.x-to-1.2.x

The documentation for modules is posted at: http://openser.org/docs/modules/1.2.x/

We would like to thank to all developers and contributors for their work with coding and testing for this new release.

Cheers, Daniel

---

Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel

Hi Klaus,

this was a collective effort - There was a huge volume of help for testing, troubleshooting and fixing problems, help coming from all over the community. Also we thanks to everybody contributing to openser , disregarding if it is about code, patches, reports, ideas, docs, etc...All this put together made this great result!

BTW, we did some tests with OpenSER 1.2.0 and today we will publish the results ;)

regards, bogdan

Klaus Darilion wrote:

congratulations!

thanks for the hard work.

regards klaus

PS: someone should make a snapshot of http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel and name it pseudovariables:1.2.x and update openser.org/docs

regards klaus

Daniel-Constantin Mierla wrote:

...

Hello,

version 1.2.0 of OpenSER has been released. It is major release, which means that you get along a lot of new features and improvements to existing ones in old versions. The configuration file and database structure suffered some changers, please read careful release notes to learn how to update.

Just to list few of the new features:

• SIMPLE Presence support

(http://openser.org/dokuwiki/doku.php/presence:presence-module)

• SNMP (http://openser.org/docs/modules/devel/snmpstats.html)
• PERL API (http://openser.org/docs/modules/devel/perl.html)
• JAVA SIP Servlet Application Server (http://wesip.eu)
• script variables and transformations

(http://openser.org/dokuwiki/doku.php/transformations:devel)

• DNS failover
• IP blacklists
• XMPP IM gateway
• XMLRPC
• SIP session timers
• secure federation peering
• retransmission timer accuracy
• usrloc refurbished for better performances
• automatic error handling
• AVPs in reply routes

Read full release notes at: http://www.openser.org/mos/view/OpenSER-v1.2.x-Release-Notes/

Source tarball can be downloaded from: http://www.openser.org/pub/openser/latest/src/ Or SourceForge: http://sourceforge.net/project/showfiles.php?group_id=139143&package_id=...

This is the first release coming out o SVN. Old CVS repository was migrated to SVN, and with these, a few changes apply to get sources from repository. Please read instructions from download page: http://www.openser.org/mos/view/Download/

Migration instructions (although not complete, I'm sure) are available at: http://openser.org/dokuwiki/doku.php/install:1.1.x-to-1.2.x

The documentation for modules is posted at: http://openser.org/docs/modules/1.2.x/

We would like to thank to all developers and contributors for their work with coding and testing for this new release.

Cheers, Daniel

---

Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel

Hi,

Just throwing wild ideas ... but if we moved to autotools (we need to look for a guru ... I agree, more than autotools is auto-chaos) we could easily cross-compile ... And that said, it just comes to mind the chance of cross-compiling with mingw and have a windows openser, just for the non-linux user and expand our borders. It may be a cut down version to start with, but wouldn't it be great?

Cesc

On 3/28/07, wanding wang wang.wanding@gmail.com wrote:

While I tried to modify the code, I found it is a big challenge for the newbie to understand the make and build system.

Just wondering if anybody is considering use CMake to replace the autotool. KDE4 is now using this user-friendly and cross-system build system, so I assume it will become more popular.

Wanding. Everything is possible. Everytime I am thinking.

On 3/14/07, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:

...

Hi Klaus,

this was a collective effort - There was a huge volume of help for testing, troubleshooting and fixing problems, help coming from all over the community. Also we thanks to everybody contributing to openser , disregarding if it is about code, patches, reports, ideas, docs, etc...All this put together made this great result!

BTW, we did some tests with OpenSER 1.2.0 and today we will publish the results ;)

regards, bogdan

Klaus Darilion wrote:

...

congratulations!

thanks for the hard work.

regards klaus

PS: someone should make a snapshot of

http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel and

...

...

name it pseudovariables: 1.2.x and update openser.org/docs

regards klaus

Daniel-Constantin Mierla wrote:

...

Hello,

version 1.2.0 of OpenSER has been released. It is major release, which means that you get along a lot of new features and improvements to existing ones in old versions. The configuration file and database structure suffered some changers, please read careful release notes to learn how to update.

Just to list few of the new features:

• SIMPLE Presence support

(

http://openser.org/dokuwiki/doku.php/presence:presence-module)

...

...

...

• SNMP

(http://openser.org/docs/modules/devel/snmpstats.html)

...

...

...

• PERL API (

http://openser.org/docs/modules/devel/perl.html)

...

...

...

• JAVA SIP Servlet Application Server (http://wesip.eu)
• script variables and transformations

(http://openser.org/dokuwiki/doku.php/transformations:devel)

...

...

...

• DNS failover
• IP blacklists
• XMPP IM gateway
• XMLRPC
• SIP session timers
• secure federation peering
• retransmission timer accuracy
• usrloc refurbished for better performances
• automatic error handling
• AVPs in reply routes

Read full release notes at:

http://www.openser.org/mos/view/OpenSER-v1.2.x-Release-Notes/

...

...

...

Source tarball can be downloaded from: http://www.openser.org/pub/openser/latest/src/ Or SourceForge:

http://sourceforge.net/project/showfiles.php?group_id=139143&package_id=...

...

...

...

This is the first release coming out o SVN. Old CVS repository was migrated to SVN, and with these, a few changes apply to get sources from repository. Please read instructions from download page: http://www.openser.org/mos/view/Download/

Migration instructions (although not complete, I'm sure) are available at:

http://openser.org/dokuwiki/doku.php/install:1.1.x-to-1.2.x

...

...

...

The documentation for modules is posted at: http://openser.org/docs/modules/1.2.x/

We would like to thank to all developers and contributors for their work with coding and testing for this new release.

Cheers, Daniel

---

Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel

---

Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel

---

Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel

On 3/30/07, Henning Westerholt henning.westerholt@1und1.de wrote:

On Friday 30 March 2007 01:00, Cesc wrote:

...

Hi,

Just throwing wild ideas ... but if we moved to autotools (we need to look for a guru ... I agree, more than autotools is auto-chaos) we could easily cross-compile ... And that said, it just comes to mind the chance of cross-compiling with mingw and have a windows openser, just for the non-linux user and expand our borders. It may be a cut down version to start with, but wouldn't it be great?

Hi Cesc,

i don't think that it would be so easy to port openser to windows, there are many Unix/ Linux specific thinks specified deep in the code.

More easy cross-compiling could be nice. But then we should use cmake instead of autotools, like the KDE project, because this is usable even for non-gurus like me. :-)

Cheers,

Henning

Hi,

Well, never used cmake myself, so can't tell. Autotools is complicated if starting from scratch, but if using existing configs from some other project, the jumpstart is very big.

As for the port ... i would expect some difficulties in some parts, like locking, loging and memory mgmnt ... also some database access libraries ... but maybe a simple, very cut-down version, with basic functionality, could be realized ...

Just brainstorming ...

Cesc

On Friday 30 March 2007 01:00, Cesc wrote:

Hi,

Just throwing wild ideas ... but if we moved to autotools (we need to look for a guru ... I agree, more than autotools is auto-chaos) we could easily cross-compile ... And that said, it just comes to mind the chance of cross-compiling with mingw and have a windows openser, just for the non-linux user and expand our borders. It may be a cut down version to start with, but wouldn't it be great?

No. Posix based software was in general never intended to run on Windows. More often than not the additional effort isn't worth it and another thing to pull away from core development. This is not even to mention the packaging effort which goes with it as the MS crowd expects binaries. Finding a developer which will solely handle the entire task is difficult and once you open the box someone is stuck with it from there on. Feel free to ignore this as it's just my observation from what I have seen in quite a few projects which this was requested and attempted.

Cheers,

Christopher

On 3/30/07, Henning Westerholt henning.westerholt@1und1.de wrote:

On Friday 30 March 2007 12:51, C. Bergström wrote:

...

...

Just throwing wild ideas ... but if we moved to autotools (we need to look for a guru ... I agree, more than autotools is auto-chaos) we could easily cross-compile ... And that said, it just comes to mind the chance of cross-compiling with mingw and have a windows openser, just for the non-linux user and expand our borders. It may be a cut down version to start with, but wouldn't it be great?

No. Posix based software was in general never intended to run on Windows. More often than not the additional effort isn't worth it and another thing to pull away from core development. [...]

The effort could be quite high, you're right. And i don't think it is right thing to do to port every free software project on the planet to the MS Windows platform, if they want to use e.g. OpenSER, they should use linux or a other unix system. :-)

If anybody want to pay a developer for this, then it is another question. But it is also my opionion that this work should not be done from the core development team.

Best regards,

Henning

I agree that this could mean quite some effort, that it need not be directly supported by the core team, but there is a lot of satelite developers who may do that in their "free time", as a hobby. I don't agree in the monolithic version of "only linux" ... running on another platform, being portable, opens a whole new bunch of oportunities to any project ... For one, in my company, we run embedded linux AND windows embedded ... but we cannot have the same proxy on both platforms, so you have to support two software units ... that is work!

Cesc

On 3/30/07, Juha Heinanen jh@tutpro.com wrote:

Cesc writes:

...

For one, in my company, we run embedded linux AND windows embedded ... but we cannot have the same proxy on both platforms, so you have to support two software units ... that is work!

why don't you ask your windows software to be ported to linux? then you would have only one platform to worry about.

-- juha

:) yes, i know, there is always two faces to a story ...

Look, the "my-work" example was just to show that being flexible and open is not bad ... of course it takes more effort; this is like all in life, pros and cons.

Basically, going back to the origins of this thread: I think we should not bluntly discard new building ways just because one of the outcomes may be a windows-based openser. Now, if all the porting needed can be done with the current makefiles ... ok then.

Cesc

wanding wang writes:

So why not try to see the beautiful scene if Openser can run on every kind of server platform?

because that will eat resources that would otherwise go into development of new features, enhancing performance, fixing bugs, responding to mailing list messages, etc.

-- juha

Hi Daniel,

Core team support ... this work would need not be done by the core team, but if in-depth support in the form of inside knowledge was offered, that should be enough to start with ... Once the cross-compile environment is setup and running, to be used by everyone, this would be a job of everyone to maintain.

Cesc

On 3/30/07, Daniel-Constantin Mierla daniel@voice-system.ro wrote:

Hello,

On 03/30/07 12:30, Cesc wrote:

...

On 3/30/07, Henning Westerholt henning.westerholt@1und1.de wrote:

...

On Friday 30 March 2007 01:00, Cesc wrote:

...

Hi,

Just throwing wild ideas ... but if we moved to autotools (we need to look for a guru ... I agree, more than autotools is auto-chaos) we could easily cross-compile ... And that said, it just comes to mind the chance of cross-compiling with mingw and have a windows openser, just for the non-linux user and expand our borders. It may be a cut down version to start with, but wouldn't it be great?

Hi Cesc,

i don't think that it would be so easy to port openser to windows, there are many Unix/ Linux specific thinks specified deep in the code.

More easy cross-compiling could be nice. But then we should use cmake instead of autotools, like the KDE project, because this is usable even for non-gurus like me. :-)

Cheers,

Henning

Hi,

Well, never used cmake myself, so can't tell. Autotools is complicated if starting from scratch, but if using existing configs from some other project, the jumpstart is very big.

As for the port ... i would expect some difficulties in some parts, like locking, loging and memory mgmnt ... also some database access libraries ... but maybe a simple, very cut-down version, with basic functionality, could be realized ...

database should not rise issues. For locking/memory can be used sysv. The module interface should be analyzed. Won't be easy, though...

Cheers, Daniel

...

Just brainstorming ...

Cesc

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi Cesc,

that is totally true - the key question is actually if we need autotools - the current makefile is self-configuring (autodetection) and so far worked mainly with no problems. So - are there some major problems to push us to autotools?? otherwise, without a guru with free time, it will be something that will make our lives more complicated.

regards, Bogdan

Cesc wrote:

Just throwing wild ideas ... but if we moved to autotools (we need to look for a guru ... I agree, more than autotools is auto-chaos)