POCO C++ Libraries

The use of the subsystem was one reason to start a Poco module. Because
MongoDB is NoSQL it would be a lot of work to use the Data interfaces.
Everything that is send to and received from the server is in BSON format.

Franky

Sent from my Android
Op 24 sep. 2012 21:34 schreef "Aleksandar Fabijanic" <alex@...>
het volgende:

> > On Mon, Sep 24, 2012 at 1:18 PM, Franky Braem <franky.braem@...>
> wrote:
> >> On 09/24/2012 06:36 AM, Aleksandar Fabijanic wrote:
> >>
> >> I'm currently reworking the MongoDB subsystem (
> >> http://mongosubsystem.sourceforge.net/) into a Poco module. If
> interested I
> >> am happy to donate it to Poco.
> >
> > Sure, commit it to the sandbox.
>
> Just out of curiosity: why was this implemented as a subsystem? I
> suspect Poco::Data back-end was ruled out due to the framework being
> too SQL-biased?
>
> I'm also CC-ing the original author to hear from the source.
>
> Alex
>

On Tue, Sep 25, 2012 at 1:32 AM, Franky Braem <franky.braem@...> wrote:
> The use of the subsystem was one reason to start a Poco module. Because

I'm not sure I understand - can you elaborate on it little bit more?

> MongoDB is NoSQL it would be a lot of work to use the Data interfaces.

Ok, I get this and can appreciate the difficulties of fitting the
noSQL square into the round SQL hole. But what troubles me is tight
coupling with the Poco::Subsystem. Is there a reason why BSON and
MongoDB couldn't be decoupled into separate libraries? In other words,
keep the MongoSubsystem but extract MongoDB and BSON into separate
libraries.

> Everything that is send to and received from the server is in BSON format.

Like with JSON, would it make sense to have Poco::BSON?

Just my two cents to this effort. I'd love to have MongoDB support in Poco.

>
> Franky
>
> Sent from my Android
>
> Op 24 sep. 2012 21:34 schreef "Aleksandar Fabijanic" <alex@...>
> het volgende:
>
>> > On Mon, Sep 24, 2012 at 1:18 PM, Franky Braem <franky.braem@...>
>> > wrote:
>> >> On 09/24/2012 06:36 AM, Aleksandar Fabijanic wrote:
>> >>
>> >> I'm currently reworking the MongoDB subsystem (
>> >> http://mongosubsystem.sourceforge.net/) into a Poco module. If
>> >> interested I
>> >> am happy to donate it to Poco.
>> >
>> > Sure, commit it to the sandbox.
>>
>> Just out of curiosity: why was this implemented as a subsystem? I
>> suspect Poco::Data back-end was ruled out due to the framework being
>> too SQL-biased?
>>
>> I'm also CC-ing the original author to hear from the source.
>>
>> Alex
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> poco-develop mailing list
> poco-develop@...
> https://lists.sourceforge.net/lists/listinfo/poco-develop
>

On 09/25/2012 06:10 PM, Aleksandar Fabijanic wrote:
> On Tue, Sep 25, 2012 at 1:32 AM, Franky Braem<franky.braem@...>  wrote:
>> The use of the subsystem was one reason to start a Poco module. Because
> I'm not sure I understand - can you elaborate on it little bit more?

My problem was that the subsystem initializes a connection pool which 
gets its parameters to connect to MongoDB from a configuration. There 
was no way in using a connection pool without using the configuration. 
So I removed it because it didn't do what I wanted. Maybe I can add some 
more general MongoSubsystem. And some of the MongoDB driver requirements 
were not implemented. For example: A MongoDB driver must implement a way 
to get the address of the master db from a replicaset.

>
>> MongoDB is NoSQL it would be a lot of work to use the Data interfaces.
> Ok, I get this and can appreciate the difficulties of fitting the
> noSQL square into the round SQL hole. But what troubles me is tight
> coupling with the Poco::Subsystem. Is there a reason why BSON and
> MongoDB couldn't be decoupled into separate libraries? In other words,
> keep the MongoSubsystem but extract MongoDB and BSON into separate
> libraries.

I don't know if BSON needs to be in a separate library. If you look at 
the bsonspec website, the only use is MongoDB. If BSON gets more 
popular, a separate library could be justifiable.

Franky.

On Tue, Sep 25, 2012 at 11:44 AM, Franky Braem <franky.braem@...> wrote:
> On 09/25/2012 06:10 PM, Aleksandar Fabijanic wrote:
>> On Tue, Sep 25, 2012 at 1:32 AM, Franky Braem<franky.braem@...>  wrote:
>>> The use of the subsystem was one reason to start a Poco module. Because
>> I'm not sure I understand - can you elaborate on it little bit more?
>
> My problem was that the subsystem initializes a connection pool which
> gets its parameters to connect to MongoDB from a configuration. There
> was no way in using a connection pool without using the configuration.

Perhaps it's me, but I'm still struggling to get the whole picture and
understanding of the design rationale. Why not just extract the
essence (MongoDB connection, pooling and DB interaction functionality)
and make it a separate library?

What I'm talking about is getting out the MongoDB related stuff into a
separate library. Subsystem, Configuration etc. - all those things can
be added later through a design similar to Logging, where you can log
without linking to Util, yet when you create Application, everything
you need is there - configuration (from files), subsystem, etc.

Shortly, the project is now a standalone module with Poco dependency.
If it is to become a part of Poco, it should be redesigned along the
above lines. At least that's my view of proper design.

I do understand and agree with the rationale for not having the
separate BSON library at this time.

Alex

On 09/25/2012 09:21 PM, Aleksandar Fabijanic wrote:
> On Tue, Sep 25, 2012 at 11:44 AM, Franky Braem<franky.braem@...>  wrote:
>> On 09/25/2012 06:10 PM, Aleksandar Fabijanic wrote:
>>> On Tue, Sep 25, 2012 at 1:32 AM, Franky Braem<franky.braem@...>   wrote:
>>>> The use of the subsystem was one reason to start a Poco module. Because
>>> I'm not sure I understand - can you elaborate on it little bit more?
>> My problem was that the subsystem initializes a connection pool which
>> gets its parameters to connect to MongoDB from a configuration. There
>> was no way in using a connection pool without using the configuration.
> Perhaps it's me, but I'm still struggling to get the whole picture and
> understanding of the design rationale. Why not just extract the
> essence (MongoDB connection, pooling and DB interaction functionality)
> and make it a separate library?
>
> What I'm talking about is getting out the MongoDB related stuff into a
> separate library. Subsystem, Configuration etc. - all those things can
> be added later through a design similar to Logging, where you can log
> without linking to Util, yet when you create Application, everything
> you need is there - configuration (from files), subsystem, etc.
>
Well I think we have a misunderstanding here. It's exactly what I'm 
doing. Remove the subsystem and create a separate MongoDB library.

Franky

On 09/24/2012 06:36 AM, Aleksandar Fabijanic wrote:
> POCO developers and users:
>
> 1.5 will be released this week, most likely Tuesday. This will be a
> transitional release, an important milestone on the way toward 1.6 and
> 2.0. All are encouraged to check the trunk out, compile, run tests and
> report any problems.
>
> We are stil using old trunk:
>
> ---
> https://poco.svn.sourceforge.net/svnroot/poco/poco/trunk

Damn, is that why I have problems again with Poco/Data/Nullable.h?
I work on an old laptop with Ubuntu 32-bit and for compiling Poco I have 
to be patient ... I'll switch back to the old trunk and try to perform 
some tests ...

> ---
>
> An appeal for contributors:
>
> We appreciate every contribution very much. But, please, please, read
> the Coding Style Guide (
> http://www.appinf.com/download/CppCodingStyleGuide.pdf ) before
> writing code. Please use tabs (not spaces) for indentation - set your
> editor to tabs (of 4-space size) for readability. We throw by value,
> catch by reference. We put one line between member function
> declarations and two lines between definitions, etc. These may seem
> like small and unimportant issues but when one spends hours and days
> fixing them, it becomes a problem. Easier your contribution is to
> integrate, sooner you'll see it released.

I'll try to do my best (and that's not good enough, I know ...)

> Again, all contributions are welcome and very much appreciated. Keep
> them coming, we need all the help we can get. Help any way you can -
> compile and run test, write howtos, evangelize ... just contribute in
> some way. And if you have submitted a patch which was not applied yet,
> or asked for a feature not implemented, we apologize - there's very
> few of us and we do our best, we'll get to it as soon as we can.

I'm currently reworking the MongoDB subsystem ( 
http://mongosubsystem.sourceforge.net/) into a Poco module. If 
interested I am happy to donate it to Poco.

>
> Thank you all and look out for the next release of POCO - 1.5.
>
I am

Franky

On Mon, Sep 24, 2012 at 1:18 PM, Franky Braem <franky.braem@...> wrote:
> On 09/24/2012 06:36 AM, Aleksandar Fabijanic wrote:
>
> We are stil using old trunk:
> ---
> https://poco.svn.sourceforge.net/svnroot/poco/poco/trunk
>
> Damn, is that why I have problems again with Poco/Data/Nullable.h?

Yes, there were two of them (in Foundation and Data) and there is only
Poco/Nullable.h in Foundation now.

> I'm currently reworking the MongoDB subsystem (
> http://mongosubsystem.sourceforge.net/) into a Poco module. If interested I
> am happy to donate it to Poco.

Sure, commit it to the sandbox.

Alex

I've got some emails from folks trying to "squeeze" more features into
this release. Admittedly, some have been sitting in the feature
request system for a long time, I just could not get to them with all
the other workload. Heck, I couldn't get in some of my own feature
requests. The problem is, adding a feature last-minute is not just
copy/pasting code - every addition takes time to review and then,
there are tests on multiple platforms, multiple compilers etc.

If it is of any comfort, we pledge to stick with "release early,
release often" mantra in the future, so please bear with us.

Alex

On Sun, Sep 23, 2012 at 11:36 PM, Aleksandar Fabijanic
<alex@...> wrote:
> POCO developers and users:
>
> 1.5 will be released this week, most likely Tuesday. This will be a
> transitional release, an important milestone on the way toward 1.6 and
> 2.0. All are encouraged to check the trunk out, compile, run tests and
> report any problems.
>
> We are stil using old trunk:
>
> ---
> https://poco.svn.sourceforge.net/svnroot/poco/poco/trunk
> ---
>
> An appeal for contributors:
>
> We appreciate every contribution very much. But, please, please, read
> the Coding Style Guide (
> http://www.appinf.com/download/CppCodingStyleGuide.pdf ) before
> writing code. Please use tabs (not spaces) for indentation - set your
> editor to tabs (of 4-space size) for readability. We throw by value,
> catch by reference. We put one line between member function
> declarations and two lines between definitions, etc. These may seem
> like small and unimportant issues but when one spends hours and days
> fixing them, it becomes a problem. Easier your contribution is to
> integrate, sooner you'll see it released.
>
> Again, all contributions are welcome and very much appreciated. Keep
> them coming, we need all the help we can get. Help any way you can -
> compile and run test, write howtos, evangelize ... just contribute in
> some way. And if you have submitted a patch which was not applied yet,
> or asked for a feature not implemented, we apologize - there's very
> few of us and we do our best, we'll get to it as soon as we can.
>
> Thank you all and look out for the next release of POCO - 1.5.
>
> Alex

I assume this has to do with NetworkInterface physical parameters and AF_LINK. If so, that can be omitted for 1.5, which is a transitional/development release with major changes, some of them code-breaking and it will fully support only the big three (Mac/BSD, Linux, windows)

Aleksandar Fabijanic

Sent from my iPhone

On Sep 17, 2012, at 17:54, Philip Prindeville <philipp_subx@...> wrote:

> How many people use Solaris?  What versions?
> 
> Are they also using Illumos or Open Solaris?
> 
> I ask because I'm looking at a complex bit of functionality in Poco that is encountering several library and kernel-level bugs in Open Solaris 11, and I'm wondering if this functionality will be missed if we just skip it.
> 
> Supporting it on Solaris might end up being as much work as initially porting it to 3 other environments (BSD/MacOS X, Linux, and Windows).
> 
> -Philip
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> poco-develop mailing list
> poco-develop@...
> https://lists.sourceforge.net/lists/listinfo/poco-develop
>

That's a relief, because Oracle stop sharing source and it's not clear they're anxious to fix this any time soon.

Alternatively, it might work if we use glibc-2 with Poco on Solaris... but there are still some ugly bugs in the Solaris kernel.  I filed 3 defects today.


On 9/17/12 7:44 PM, Alex Fabijanic wrote:
> I assume this has to do with NetworkInterface physical parameters and AF_LINK. If so, that can be omitted for 1.5, which is a transitional/development release with major changes, some of them code-breaking and it will fully support only the big three (Mac/BSD, Linux, windows)
>
> Aleksandar Fabijanic
>
> Sent from my iPhone
>
> On Sep 17, 2012, at 17:54, Philip Prindeville <philipp_subx@...> wrote:
>
>> How many people use Solaris?  What versions?
>>
>> Are they also using Illumos or Open Solaris?
>>
>> I ask because I'm looking at a complex bit of functionality in Poco that is encountering several library and kernel-level bugs in Open Solaris 11, and I'm wondering if this functionality will be missed if we just skip it.
>>
>> Supporting it on Solaris might end up being as much work as initially porting it to 3 other environments (BSD/MacOS X, Linux, and Windows).
>>
>> -Philip
>>

What platforms are out there anyway that don't support getifaddrs() correctly (i.e. that don't include interfaces that are present but not configured)?

We might have to provide a replacement version of getifaddrs() to do the right thing.

I was poking around doing such a thing for Open Solaris 11 yesterday, and I noticed that (a) it didn't agree with the man pages, (2) the old BSD-standard ioctl's were partially broken and only the new "long-style" ioctl's (SIOCGLIF*) seemed to work, and (c) a lot of this damage has been around for a while as a known issue.

Since Oracle isn't sharing source and isn't fixing well-known bugs, that means that the support burden for Solaris is going to be substantially higher than other platforms.

-Philip



On 9/17/12 9:06 PM, Philip Prindeville wrote:
> That's a relief, because Oracle stop sharing source and it's not clear they're anxious to fix this any time soon.
> 
> Alternatively, it might work if we use glibc-2 with Poco on Solaris... but there are still some ugly bugs in the Solaris kernel.  I filed 3 defects today.

Android also doesn't have <ifaddrs.h>, I had to comment all instances that
use it so it would compile.

On Tue, Sep 18, 2012 at 2:09 PM, Philip Prindeville <
philipp_subx@...> wrote:

> What platforms are out there anyway that don't support getifaddrs()
> correctly (i.e. that don't include interfaces that are present but not
> configured)?
>
> We might have to provide a replacement version of getifaddrs() to do the
> right thing.
>
> I was poking around doing such a thing for Open Solaris 11 yesterday, and
> I noticed that (a) it didn't agree with the man pages, (2) the old
> BSD-standard ioctl's were partially broken and only the new "long-style"
> ioctl's (SIOCGLIF*) seemed to work, and (c) a lot of this damage has been
> around for a while as a known issue.
>
> Since Oracle isn't sharing source and isn't fixing well-known bugs, that
> means that the support burden for Solaris is going to be substantially
> higher than other platforms.
>
> -Philip
>
>
>
> On 9/17/12 9:06 PM, Philip Prindeville wrote:
> > That's a relief, because Oracle stop sharing source and it's not clear
> they're anxious to fix this any time soon.
> >
> > Alternatively, it might work if we use glibc-2 with Poco on Solaris...
> but there are still some ugly bugs in the Solaris kernel.  I filed 3
> defects today.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> poco-develop mailing list
> poco-develop@...
> https://lists.sourceforge.net/lists/listinfo/poco-develop
>

Odd, because Android is Linux and uses glibc.

If I provide a mock-up of getifaddrs() for Solaris, can you port it to Android?

-Philip

On 9/18/12 11:38 AM, Rangel Reale wrote:
> Android also doesn't have <ifaddrs.h>, I had to comment all instances that use it so it would compile.
> 
> On Tue, Sep 18, 2012 at 2:09 PM, Philip Prindeville <philipp_subx@... <mailto:philipp_subx@...>> wrote:
> 
>     What platforms are out there anyway that don't support getifaddrs() correctly (i.e. that don't include interfaces that are present but not configured)?
> 
>     We might have to provide a replacement version of getifaddrs() to do the right thing.
> 
>     I was poking around doing such a thing for Open Solaris 11 yesterday, and I noticed that (a) it didn't agree with the man pages, (2) the old BSD-standard ioctl's were partially broken and only the new "long-style" ioctl's (SIOCGLIF*) seemed to work, and (c) a lot of this damage has been around for a while as a known issue.
> 
>     Since Oracle isn't sharing source and isn't fixing well-known bugs, that means that the support burden for Solaris is going to be substantially higher than other platforms.
> 
>     -Philip
> 
> 
> 
>     On 9/17/12 9:06 PM, Philip Prindeville wrote:
>     > That's a relief, because Oracle stop sharing source and it's not clear they're anxious to fix this any time soon.
>     >
>     > Alternatively, it might work if we use glibc-2 with Poco on Solaris... but there are still some ugly bugs in the Solaris kernel.  I filed 3 defects today.

Yes, I'm activelly testing trunk on Android, I can port to Android if
possible.
According to this topic:
https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/3JIvD0PFaU4

" The two usual ways of doing this on any Linux kernel is via
SIOCGIFCONF ioctl calls or netlink. "

It may be the same as the SIOCGLIF you were talking about.


On Tue, Sep 18, 2012 at 3:32 PM, Philip Prindeville <
philipp_subx@...> wrote:

> Odd, because Android is Linux and uses glibc.
>
> If I provide a mock-up of getifaddrs() for Solaris, can you port it to
> Android?
>
> -Philip
>
> On 9/18/12 11:38 AM, Rangel Reale wrote:
> > Android also doesn't have <ifaddrs.h>, I had to comment all instances
> that use it so it would compile.
> >
> > On Tue, Sep 18, 2012 at 2:09 PM, Philip Prindeville <
> philipp_subx@... <mailto:
> philipp_subx@...>> wrote:
> >
> >     What platforms are out there anyway that don't support getifaddrs()
> correctly (i.e. that don't include interfaces that are present but not
> configured)?
> >
> >     We might have to provide a replacement version of getifaddrs() to do
> the right thing.
> >
> >     I was poking around doing such a thing for Open Solaris 11
> yesterday, and I noticed that (a) it didn't agree with the man pages, (2)
> the old BSD-standard ioctl's were partially broken and only the new
> "long-style" ioctl's (SIOCGLIF*) seemed to work, and (c) a lot of this
> damage has been around for a while as a known issue.
> >
> >     Since Oracle isn't sharing source and isn't fixing well-known bugs,
> that means that the support burden for Solaris is going to be substantially
> higher than other platforms.
> >
> >     -Philip
> >
> >
> >
> >     On 9/17/12 9:06 PM, Philip Prindeville wrote:
> >     > That's a relief, because Oracle stop sharing source and it's not
> clear they're anxious to fix this any time soon.
> >     >
> >     > Alternatively, it might work if we use glibc-2 with Poco on
> Solaris... but there are still some ugly bugs in the Solaris kernel.  I
> filed 3 defects today.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> poco-develop mailing list
> poco-develop@...
> https://lists.sourceforge.net/lists/listinfo/poco-develop
>

I agree, we'll have to go ioctl SIOCGIFCONF route to support all platforms. Won't happen in 1.5 though

Aleksandar Fabijanic

Sent from my iPhone

On Sep 18, 2012, at 14:41, Rangel Reale <rangelreale@...> wrote:

> Yes, I'm activelly testing trunk on Android, I can port to Android if possible.
> According to this topic:
> https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/3JIvD0PFaU4 
> 
> " The two usual ways of doing this on any Linux kernel is via
> SIOCGIFCONF ioctl calls or netlink. "
> 
> It may be the same as the SIOCGLIF you were talking about.
> 
> 
> On Tue, Sep 18, 2012 at 3:32 PM, Philip Prindeville <philipp_subx@...> wrote:
> Odd, because Android is Linux and uses glibc.
> 
> If I provide a mock-up of getifaddrs() for Solaris, can you port it to Android?
> 
> -Philip
> 
> On 9/18/12 11:38 AM, Rangel Reale wrote:
> > Android also doesn't have <ifaddrs.h>, I had to comment all instances that use it so it would compile.
> >
> > On Tue, Sep 18, 2012 at 2:09 PM, Philip Prindeville <philipp_subx@... <mailto:philipp_subx@...>> wrote:
> >
> >     What platforms are out there anyway that don't support getifaddrs() correctly (i.e. that don't include interfaces that are present but not configured)?
> >
> >     We might have to provide a replacement version of getifaddrs() to do the right thing.
> >
> >     I was poking around doing such a thing for Open Solaris 11 yesterday, and I noticed that (a) it didn't agree with the man pages, (2) the old BSD-standard ioctl's were partially broken and only the new "long-style" ioctl's (SIOCGLIF*) seemed to work, and (c) a lot of this damage has been around for a while as a known issue.
> >
> >     Since Oracle isn't sharing source and isn't fixing well-known bugs, that means that the support burden for Solaris is going to be substantially higher than other platforms.
> >
> >     -Philip
> >
> >
> >
> >     On 9/17/12 9:06 PM, Philip Prindeville wrote:
> >     > That's a relief, because Oracle stop sharing source and it's not clear they're anxious to fix this any time soon.
> >     >
> >     > Alternatively, it might work if we use glibc-2 with Poco on Solaris... but there are still some ugly bugs in the Solaris kernel.  I filed 3 defects today.
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> poco-develop mailing list
> poco-develop@...
> https://lists.sourceforge.net/lists/listinfo/poco-develop
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> poco-develop mailing list
> poco-develop@...
> https://lists.sourceforge.net/lists/listinfo/poco-develop

SIOGLIFCONF is a travesty introduced on Solaris.

It's "classical" implementation on BSD is SIOCGIFCONF.

I've seen other postings decrying Android not having getifaddrs().

What version of glibc are you using?

-Philip


On 9/18/12 12:41 PM, Rangel Reale wrote:
> Yes, I'm activelly testing trunk on Android, I can port to Android if possible.
> According to this topic:
> https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/3JIvD0PFaU4 
> 
> " The two usual ways of doing this on any Linux kernel is via
> SIOCGIFCONF ioctl calls or netlink. "
> 
> It may be the same as the SIOCGLIF you were talking about.
> 
> 
> On Tue, Sep 18, 2012 at 3:32 PM, Philip Prindeville <philipp_subx@... <mailto:philipp_subx@...>> wrote:
> 
>     Odd, because Android is Linux and uses glibc.
> 
>     If I provide a mock-up of getifaddrs() for Solaris, can you port it to Android?
> 
>     -Philip
> 
>     On 9/18/12 11:38 AM, Rangel Reale wrote:
>     > Android also doesn't have <ifaddrs.h>, I had to comment all instances that use it so it would compile.
>     >
>     > On Tue, Sep 18, 2012 at 2:09 PM, Philip Prindeville <philipp_subx@... <mailto:philipp_subx@...> <mailto:philipp_subx@... <mailto:philipp_subx@...>>> wrote:
>     >
>     >     What platforms are out there anyway that don't support getifaddrs() correctly (i.e. that don't include interfaces that are present but not configured)?
>     >
>     >     We might have to provide a replacement version of getifaddrs() to do the right thing.
>     >
>     >     I was poking around doing such a thing for Open Solaris 11 yesterday, and I noticed that (a) it didn't agree with the man pages, (2) the old BSD-standard ioctl's were partially broken and only the new "long-style" ioctl's (SIOCGLIF*) seemed to work, and (c) a lot of this damage has been around for a while as a known issue.
>     >
>     >     Since Oracle isn't sharing source and isn't fixing well-known bugs, that means that the support burden for Solaris is going to be substantially higher than other platforms.
>     >
>     >     -Philip
>     >
>     >
>     >
>     >     On 9/17/12 9:06 PM, Philip Prindeville wrote:
>     >     > That's a relief, because Oracle stop sharing source and it's not clear they're anxious to fix this any time soon.
>     >     >
>     >     > Alternatively, it might work if we use glibc-2 with Poco on Solaris... but there are still some ugly bugs in the Solaris kernel.  I filed 3 defects today.

BTW, we don't use the ifa_data field (contains statistics in Linux) so the version mentioned in that posting should be adequate.


On 9/18/12 12:41 PM, Rangel Reale wrote:
> Yes, I'm activelly testing trunk on Android, I can port to Android if possible.
> According to this topic:
> https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/3JIvD0PFaU4 
> 
> " The two usual ways of doing this on any Linux kernel is via
> SIOCGIFCONF ioctl calls or netlink. "

I'm still trying to wrap my head around "all platforms".

Who doesn't implement it (or implements it incorrectly)?

-Philip


On 9/18/12 12:50 PM, Alex Fabijanic wrote:
> I agree, we'll have to go ioctl SIOCGIFCONF route to support all platforms. Won't happen in 1.5 though
> 
> Aleksandar Fabijanic

Android does not use glibc. It's based on Bionic.

-guenter

--
Günter Obiltschnig
Applied Informatics Software Engineering GmbH
A-9182 Maria Elend | Maria Elend 96/4 | http://www.appinf.com
P: +43 4253 32596  M: +43 676 5166737  F: +43 4253 32096

Company Registration: FN 276491 f | Landesgericht Klagenfurt
Managing Director: DI Günter Obiltschnig



On 18.09.2012, at 11:32, Philip Prindeville wrote:

> Odd, because Android is Linux and uses glibc.
> 
> If I provide a mock-up of getifaddrs() for Solaris, can you port it to Android?
> 
> -Philip
> 
> On 9/18/12 11:38 AM, Rangel Reale wrote:
>> Android also doesn't have <ifaddrs.h>, I had to comment all instances that use it so it would compile.
>> 
>> On Tue, Sep 18, 2012 at 2:09 PM, Philip Prindeville <philipp_subx@... <mailto:philipp_subx@...>> wrote:
>> 
>>    What platforms are out there anyway that don't support getifaddrs() correctly (i.e. that don't include interfaces that are present but not configured)?
>> 
>>    We might have to provide a replacement version of getifaddrs() to do the right thing.
>> 
>>    I was poking around doing such a thing for Open Solaris 11 yesterday, and I noticed that (a) it didn't agree with the man pages, (2) the old BSD-standard ioctl's were partially broken and only the new "long-style" ioctl's (SIOCGLIF*) seemed to work, and (c) a lot of this damage has been around for a while as a known issue.
>> 
>>    Since Oracle isn't sharing source and isn't fixing well-known bugs, that means that the support burden for Solaris is going to be substantially higher than other platforms.
>> 
>>    -Philip
>> 
>> 
>> 
>>    On 9/17/12 9:06 PM, Philip Prindeville wrote:
>>> That's a relief, because Oracle stop sharing source and it's not clear they're anxious to fix this any time soon.
>>> 
>>> Alternatively, it might work if we use glibc-2 with Poco on Solaris... but there are still some ugly bugs in the Solaris kernel.  I filed 3 defects today.
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> poco-develop mailing list
> poco-develop@...
> https://lists.sourceforge.net/lists/listinfo/poco-develop
>