On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:
> I am a Java developer who is tired of java.nio and similar complex socket libraries.
>
> In Java you got QuickServer, the ultimate protocol creation centered socket library. You don't have to write any channels and readers and what not. You just instantiate a server, configures the handlers (fill in classes that extends a handler interface) and there you go.
>
> Shouldn't there exist a similar library in any programming language? Not doing so is assuming that developers always need control of the lower layers. Its not true. I care about protocol. Not sockets.
>
> Is there any abstraction layers in phobos? Or is everything just as complex as before?

I use QuickServer myself, and was thinking about creating something like that in D for quite some time...

On Wednesday, 30 May 2012 at 08:40:48 UTC, Dejan Lekic wrote:
> On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:
>> I am a Java developer who is tired of java.nio and similar complex socket libraries.
>>
>> In Java you got QuickServer, the ultimate protocol creation centered socket library. You don't have to write any channels and readers and what not. You just instantiate a server, configures the handlers (fill in classes that extends a handler interface) and there you go.
>>
>> Shouldn't there exist a similar library in any programming language? Not doing so is assuming that developers always need control of the lower layers. Its not true. I care about protocol. Not sockets.
>>
>> Is there any abstraction layers in phobos? Or is everything just as complex as before?
>
> I use QuickServer myself, and was thinking about creating something like that in D for quite some time...

Good to hear! Your comment sparked the last in me to find out what was terribly wrong with my code. Spawning 1000 threads to the service never succeded. By investigating and copying from the listener example in std.socket library I found out that I had to use the SocketSet for all socket connections. In Java I could communicate based on a socket connection per client in multiple threads. With the berkeley api i am not able to do the same thing and it all fails tremendously if i try. Any reason why I cannot take a socket and communicate with its receive and send method solely?

On Wednesday, 30 May 2012 at 08:40:48 UTC, Dejan Lekic wrote:
> On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:
>> I am a Java developer who is tired of java.nio and similar complex socket libraries.
>>
>> In Java you got QuickServer, the ultimate protocol creation centered socket library. You don't have to write any channels and readers and what not. You just instantiate a server, configures the handlers (fill in classes that extends a handler interface) and there you go.
>>
>> Shouldn't there exist a similar library in any programming language? Not doing so is assuming that developers always need control of the lower layers. Its not true. I care about protocol. Not sockets.
>>
>> Is there any abstraction layers in phobos? Or is everything just as complex as before?
>
> I use QuickServer myself, and was thinking about creating something like that in D for quite some time...

Btw I updated my github project so now my little "quickserver" is
actually working :)

On Monday, 21 May 2012 at 19:06:24 UTC, Nathan M. Swan wrote:
> On Monday, 21 May 2012 at 17:54:56 UTC, Adam D. Ruppe wrote:
>> On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:
>>> It has some pitfalls (e.g. I can't find a good way to stop the server)
>>
>> When I use it, I just leave it open in a terminal window.
>> Control+C can then kill it. (I'm on linux but I think the
>> same would apply on Windows.)
>>
>> That's the only way right now. I was trying to make break;
>> work in that connect opApply thing, but it didn't work
>> right so there is no quit ability inside the app right now.
>
> That's what I've done too, though it fails to call destructors.
>
> I tried manager.quit(), but it results in segfaults for some reason (I think it has something to do with background threads).

Now I have removed the code that rendered the server incomatible with windows. Now documentation is the biggest todo on my list. Also notice I have added a bat script for running the simpleserver :)

On Wednesday, 30 May 2012 at 20:09:43 UTC, Jarl André wrote:
> On Monday, 21 May 2012 at 19:06:24 UTC, Nathan M. Swan wrote:
>> On Monday, 21 May 2012 at 17:54:56 UTC, Adam D. Ruppe wrote:
>>> On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:
>>>> It has some pitfalls (e.g. I can't find a good way to stop the server)
>>>
>>> When I use it, I just leave it open in a terminal window.
>>> Control+C can then kill it. (I'm on linux but I think the
>>> same would apply on Windows.)
>>>
>>> That's the only way right now. I was trying to make break;
>>> work in that connect opApply thing, but it didn't work
>>> right so there is no quit ability inside the app right now.
>>
>> That's what I've done too, though it fails to call destructors.
>>
>> I tried manager.quit(), but it results in segfaults for some reason (I think it has something to do with background threads).
>
> Now I have removed the code that rendered the server incomatible with windows. Now documentation is the biggest todo on my list. Also notice I have added a bat script for running the simpleserver :)

I replied to the wrong author but anyway, if anyone wants to contribute to this project just tell me. Cheers.

Now the similarity to the original quickserver library in java is so ripped off that I had an email sent over to the author asking for permission to continue on the api clone or alternatively change the api. Comments or suggestions? sucks totally or worth a penny?

On Wednesday, 30 May 2012 at 20:12:07 UTC, Jarl André wrote:
> On Wednesday, 30 May 2012 at 20:09:43 UTC, Jarl André wrote:
>> On Monday, 21 May 2012 at 19:06:24 UTC, Nathan M. Swan wrote:
>>> On Monday, 21 May 2012 at 17:54:56 UTC, Adam D. Ruppe wrote:
>>>> On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:
>>>>> It has some pitfalls (e.g. I can't find a good way to stop the server)
>>>>
>>>> When I use it, I just leave it open in a terminal window.
>>>> Control+C can then kill it. (I'm on linux but I think the
>>>> same would apply on Windows.)
>>>>
>>>> That's the only way right now. I was trying to make break;
>>>> work in that connect opApply thing, but it didn't work
>>>> right so there is no quit ability inside the app right now.
>>>
>>> That's what I've done too, though it fails to call destructors.
>>>
>>> I tried manager.quit(), but it results in segfaults for some reason (I think it has something to do with background threads).
>>
>> Now I have removed the code that rendered the server incomatible with windows. Now documentation is the biggest todo on my list. Also notice I have added a bat script for running the simpleserver :)
>
> I replied to the wrong author but anyway, if anyone wants to contribute to this project just tell me. Cheers.

Thank you for the Windows compatibility. I will try it out ASAP.

> Thank you for the Windows compatibility. I will try it out ASAP.

I have now added some subtle changes to the server and example echo server. I have added an example for how byte streams can be passed to the server by converting them to base64. In my example the base64 encoded data is appended to a command. In this way I do not have to think about support for reading and writing bytes to and from sockets. Its a pain so I am trying to find a way to simplify this communication. I may incorporate this base64 encode/decode into the server library, but at this point everything is in the echoserver.d file, visible for the naked eye :)

Question about Base64.decode(chomped)

Why is it possible to decode a string like "ddd"? I thought base64 was a strict format? I would like any encoder/decoder to throw exception on error not just returning whatever that was passed to the function.