I looked a little bit into node.js and libuv architecture

On Wed, Oct 17, 2012 at 9:47 PM, Alfred Tascon <atascon@gmail.com> wrote:

Do we use something like "libuv"?
do we try and solve it using poco classes, if we can, before we consider 3rd party libs?

I would be inclined to take the libev/libeio wrapper path. libuv brings in lots of networking stuff we already have.

http://software.schmorp.de/pkg/libev.html
http://software.schmorp.de/pkg/libeio.html

Alex
 

There is the C++11 bunch of async and future standard modules. Should they fit in this?
Or is the lack of compiler support a show stopper for Poco's audience?

How much refactoring will this impact?
What comes to mind is the thread/connection code and to abstract all that to use either model would be a non-trivial change, dont you think?
Maybe all that functionality needs to be duplicated to use the new async model (again non-trivial - maybe im wrong) ?

I would not take this on by myself.
But if you and others are serious about going forward with this then you can count me in.

Alfred


On 18/10/2012, at 8:22 AM, Aleksandar Fabijanic <alex@pocoproject.org> wrote:

> On Wed, Oct 17, 2012 at 6:20 PM, Alfred Tascon <atascon@gmail.com> wrote:
>> Have a look at http://nosql-database.org
>>
>> This will give a hint as to the diverse number of technologies (map/reduce, key/value pairs, documents, graphs, etc...) that are used.
>
> Much more complex than I thought it was. Perhaps it makes sense to
> leave noSQL without a front-end after all.
>
>> If I may, I would love to see async io in Poco ;)
>
> Me too ;).
>
> A more serious and less sarcastic answer: if you'd like to see a
> feature or library, it is best to contribute it; you can join forces
> with other interested parties. Or, if you need it real bad and it
> makes commercial sense for you, we'll be happy to develop it on a
> commercial basis for you in your desired timeframe (within reasonable
> limits).
>
>> and can't wait when you guys move to GitHub.
>
> Yes, things should be easier there. At least that's what they say ...
>
>>
>> Sent from my iPhone
>>
>> On 18/10/2012, at 5:18 AM, Alex Fabijanic <alex@pocoproject.org> wrote:
>>
>>> Hi James,
>>>
>>> To answer your question first: at this time, I am seeing a solution and I'm looking for a problem :)
>>>
>>> But seriously, we have someone scratching an itch here and I'm just brainstorming early in the process trying to leverage the effort for future itches. Nothing more than that.
>>>
>>> Aleksandar Fabijanic
>>>
>>> Sent from my iPhone
>>>
>>> On Oct 17, 2012, at 14:04, james <james@mansionfamily.plus.com> wrote:
>>>
>>>> I think memcache might be a key/value map, but most of the other systems have diverse facilitis in terms of matching on document content, operating on documents, representing quetes and vectors and atomic operations, and subscription to change.
>>>>
>>>> You might manage to represent it with some kind of attribute mechanism, but I'd question why, apart from 'because I can' and that's a pretty poor reason IMO.
>>>>
>>>> Also, I'd question who would use any sort of common API.  I have some sympathy for abstractions like ODBC which try to unify a half-decent SQL - but only for ISVs who need to try to deliver onto a customer choice database and don't care if the performance sucks.  I've never worked on a system where the database API amounts to anything more than noise in terms of porting the system - the actual semantics of concurrency and locking and how you architect to get decent performance has always been totally non-portable and its bad enough moving serious syetems between versions of Sybase, for example.
>>>>
>>>> What (and who's)  problem are you trying to solve with Poco::NoSQL?
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>> _______________________________________________
>>> poco-develop mailing list
>>> poco-develop@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/poco-develop
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> poco-develop mailing list
>> poco-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/poco-develop


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
poco-develop mailing list
poco-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/poco-develop