May 18, 2012
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?
May 19, 2012
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?

Check out arsd:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

I used cgi.d to make my own server easily (compile with -version=embedded_httpd). If you want more lower-level control, try a ListeningConnectionManager. To see how it's used, look at the code starting on line #1926.

It has some pitfalls (e.g. I can't find a good way to stop the server), but it is very nice in _easily_ starting up, with _zero_ config.

NMS
May 21, 2012
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.
May 21, 2012
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).

May 23, 2012
On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 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?
>
> Check out arsd:
> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
>
> I used cgi.d to make my own server easily (compile with -version=embedded_httpd). If you want more lower-level control, try a ListeningConnectionManager. To see how it's used, look at the code starting on line #1926.
>
> It has some pitfalls (e.g. I can't find a good way to stop the server), but it is very nice in _easily_ starting up, with _zero_ config.
>
> NMS

Thanks. It looks like a good option.

As it turns out I am very interested in having complete control of what type of service I am creating, so a library limiting me in some ways are not an option. On the other hand, I have investigated the listener example and have found out that I needed to generalize it a bit. Make a few interfaces, some implementations and my initial goal is to have end user code look excactly like QuickServers in Java. Why? Because sometimes you need simple command servers, lets say for polling an email or checking hardware status on a server and report it back, not worrying about blocking and async or whatever about sockets.

Another great advantage of making a "QuickServer" library is that its inner content can be replaced in the future without the end users knowing about. I have come far in the library making, but need some help understanding std.socket:

1.a. What is SocketSet and why do I need to pass it to Socket.select?
1.b. I only want to accept new sockets and I think its too much code for that

Even if questions is stupid please comment/correct me.
May 23, 2012
On Wednesday, 23 May 2012 at 13:39:09 UTC, Jarl André wrote:
> On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 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?
>>
>> Check out arsd:
>> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
>>
>> I used cgi.d to make my own server easily (compile with -version=embedded_httpd). If you want more lower-level control, try a ListeningConnectionManager. To see how it's used, look at the code starting on line #1926.
>>
>> It has some pitfalls (e.g. I can't find a good way to stop the server), but it is very nice in _easily_ starting up, with _zero_ config.
>>
>> NMS
>
> Thanks. It looks like a good option.
>
> As it turns out I am very interested in having complete control of what type of service I am creating, so a library limiting me in some ways are not an option. On the other hand, I have investigated the listener example and have found out that I needed to generalize it a bit. Make a few interfaces, some implementations and my initial goal is to have end user code look excactly like QuickServers in Java. Why? Because sometimes you need simple command servers, lets say for polling an email or checking hardware status on a server and report it back, not worrying about blocking and async or whatever about sockets.
>
> Another great advantage of making a "QuickServer" library is that its inner content can be replaced in the future without the end users knowing about. I have come far in the library making, but need some help understanding std.socket:
>
> 1.a. What is SocketSet and why do I need to pass it to Socket.select?
> 1.b. I only want to accept new sockets and I think its too much code for that
>
> Even if questions is stupid please comment/correct me.

And here it comes:

https://github.com/jarlah/d2-simple-socket-server

This is my object oriented contribution to the problem.

Based on closed/open principe, in that expansion is done by adding new classes and not modifying the existing code.

Comments are appreciated.
May 25, 2012
On Wednesday, 23 May 2012 at 19:24:53 UTC, Jarl André wrote:
> On Wednesday, 23 May 2012 at 13:39:09 UTC, Jarl André wrote:
>> On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 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?
>>>
>>> Check out arsd:
>>> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
>>>
>>> I used cgi.d to make my own server easily (compile with -version=embedded_httpd). If you want more lower-level control, try a ListeningConnectionManager. To see how it's used, look at the code starting on line #1926.
>>>
>>> It has some pitfalls (e.g. I can't find a good way to stop the server), but it is very nice in _easily_ starting up, with _zero_ config.
>>>
>>> NMS
>>
>> Thanks. It looks like a good option.
>>
>> As it turns out I am very interested in having complete control of what type of service I am creating, so a library limiting me in some ways are not an option. On the other hand, I have investigated the listener example and have found out that I needed to generalize it a bit. Make a few interfaces, some implementations and my initial goal is to have end user code look excactly like QuickServers in Java. Why? Because sometimes you need simple command servers, lets say for polling an email or checking hardware status on a server and report it back, not worrying about blocking and async or whatever about sockets.
>>
>> Another great advantage of making a "QuickServer" library is that its inner content can be replaced in the future without the end users knowing about. I have come far in the library making, but need some help understanding std.socket:
>>
>> 1.a. What is SocketSet and why do I need to pass it to Socket.select?
>> 1.b. I only want to accept new sockets and I think its too much code for that
>>
>> Even if questions is stupid please comment/correct me.
>
> And here it comes:
>
> https://github.com/jarlah/d2-simple-socket-server
>
> This is my object oriented contribution to the problem.
>
> Based on closed/open principe, in that expansion is done by adding new classes and not modifying the existing code.
>
> Comments are appreciated.

Would it be possible for someone to write some documentation on this socket server and make it windows compatible?

I am just learning D and coming from C# sockets this is much different and I understand it completely. I would much appreciate any help with understanding sockets in D and any pointers in the right direction.
May 25, 2012
On Friday, 25 May 2012 at 20:50:25 UTC, Donald Duvall wrote:
> On Wednesday, 23 May 2012 at 19:24:53 UTC, Jarl André wrote:
>> On Wednesday, 23 May 2012 at 13:39:09 UTC, Jarl André wrote:
>>> On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 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?
>>>>
>>>> Check out arsd:
>>>> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
>>>>
>>>> I used cgi.d to make my own server easily (compile with -version=embedded_httpd). If you want more lower-level control, try a ListeningConnectionManager. To see how it's used, look at the code starting on line #1926.
>>>>
>>>> It has some pitfalls (e.g. I can't find a good way to stop the server), but it is very nice in _easily_ starting up, with _zero_ config.
>>>>
>>>> NMS
>>>
>>> Thanks. It looks like a good option.
>>>
>>> As it turns out I am very interested in having complete control of what type of service I am creating, so a library limiting me in some ways are not an option. On the other hand, I have investigated the listener example and have found out that I needed to generalize it a bit. Make a few interfaces, some implementations and my initial goal is to have end user code look excactly like QuickServers in Java. Why? Because sometimes you need simple command servers, lets say for polling an email or checking hardware status on a server and report it back, not worrying about blocking and async or whatever about sockets.
>>>
>>> Another great advantage of making a "QuickServer" library is that its inner content can be replaced in the future without the end users knowing about. I have come far in the library making, but need some help understanding std.socket:
>>>
>>> 1.a. What is SocketSet and why do I need to pass it to Socket.select?
>>> 1.b. I only want to accept new sockets and I think its too much code for that
>>>
>>> Even if questions is stupid please comment/correct me.
>>
>> And here it comes:
>>
>> https://github.com/jarlah/d2-simple-socket-server
>>
>> This is my object oriented contribution to the problem.
>>
>> Based on closed/open principe, in that expansion is done by adding new classes and not modifying the existing code.
>>
>> Comments are appreciated.
>
> Would it be possible for someone to write some documentation on this socket server and make it windows compatible?
>
> I am just learning D and coming from C# sockets this is much different and I understand it completely. I would much appreciate any help with understanding sockets in D and any pointers in the right direction.

Sorry for the typo: I do NOT understand it completely.
May 27, 2012
On Friday, 25 May 2012 at 20:55:12 UTC, Donald Duvall wrote:
> On Friday, 25 May 2012 at 20:50:25 UTC, Donald Duvall wrote:
>> On Wednesday, 23 May 2012 at 19:24:53 UTC, Jarl André wrote:
>>> On Wednesday, 23 May 2012 at 13:39:09 UTC, Jarl André wrote:
>>>> On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 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?
>>>>>
>>>>> Check out arsd:
>>>>> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
>>>>>
>>>>> I used cgi.d to make my own server easily (compile with -version=embedded_httpd). If you want more lower-level control, try a ListeningConnectionManager. To see how it's used, look at the code starting on line #1926.
>>>>>
>>>>> It has some pitfalls (e.g. I can't find a good way to stop the server), but it is very nice in _easily_ starting up, with _zero_ config.
>>>>>
>>>>> NMS
>>>>
>>>> Thanks. It looks like a good option.
>>>>
>>>> As it turns out I am very interested in having complete control of what type of service I am creating, so a library limiting me in some ways are not an option. On the other hand, I have investigated the listener example and have found out that I needed to generalize it a bit. Make a few interfaces, some implementations and my initial goal is to have end user code look excactly like QuickServers in Java. Why? Because sometimes you need simple command servers, lets say for polling an email or checking hardware status on a server and report it back, not worrying about blocking and async or whatever about sockets.
>>>>
>>>> Another great advantage of making a "QuickServer" library is that its inner content can be replaced in the future without the end users knowing about. I have come far in the library making, but need some help understanding std.socket:
>>>>
>>>> 1.a. What is SocketSet and why do I need to pass it to Socket.select?
>>>> 1.b. I only want to accept new sockets and I think its too much code for that
>>>>
>>>> Even if questions is stupid please comment/correct me.
>>>
>>> And here it comes:
>>>
>>> https://github.com/jarlah/d2-simple-socket-server
>>>
>>> This is my object oriented contribution to the problem.
>>>
>>> Based on closed/open principe, in that expansion is done by adding new classes and not modifying the existing code.
>>>
>>> Comments are appreciated.
>>
>> Would it be possible for someone to write some documentation on this socket server and make it windows compatible?
>>
>> I am just learning D and coming from C# sockets this is much different and I understand it completely. I would much appreciate any help with understanding sockets in D and any pointers in the right direction.
>
> Sorry for the typo: I do NOT understand it completely.

Thanks for the feedback! Well, for me I am a Java enterprise developer working with Java on Unix, but, I have worked with .NET in the past giving me a tiny portion of mercy to those that enjoys Visual Studio :) Its actually a blazing fast IDE. Enough digression.

The last days I have completely rewritten the library, and have also added a build script (you can just rename it from "simpleserver.sh" to "simpleserver.bat" and it will work. However, there are two things about this library that I am currently working on:

1. Windows support is lacking because I use a thread pool with imports for posix (unix systems) and I'm not extremely good at D yet.

2. For some reason I left an implementation of AbstractClientCommandHamdler in the quickserver library but it was intentional that this should reside in the simpleserver.d file, completely closing the library and making it possible to create a server without modifying the library at all.

3. I am wondering if I should export the threadpool into its own library so not to clutter up the quickserver.d file with Windows/Posix compability code. At the moment the server itslf is system independent.

So the answer is: yes I'll try to look at windows support, but if someone wants to help me I'll gladly say yes.

May 27, 2012
>> Sorry for the typo: I do NOT understand it completely.
>
> Thanks for the feedback! Well, for me I am a Java enterprise developer working with Java on Unix, but, I have worked with .NET in the past giving me a tiny portion of mercy to those that enjoys Visual Studio :) Its actually a blazing fast IDE. Enough digression.
>
> The last days I have completely rewritten the library, and have also added a build script (you can just rename it from "simpleserver.sh" to "simpleserver.bat" and it will work. However, there are two things about this library that I am currently working on:
>
> 1. Windows support is lacking because I use a thread pool with imports for posix (unix systems) and I'm not extremely good at D yet.
>
> 2. For some reason I left an implementation of AbstractClientCommandHamdler in the quickserver library but it was intentional that this should reside in the simpleserver.d file, completely closing the library and making it possible to create a server without modifying the library at all.
>
> 3. I am wondering if I should export the threadpool into its own library so not to clutter up the quickserver.d file with Windows/Posix compability code. At the moment the server itslf is system independent.
>
> So the answer is: yes I'll try to look at windows support, but if someone wants to help me I'll gladly say yes.

I completed todo 2 and 3. Now lets hope someone wants to contribute cross compability code on todo 1. It should be fairly easy since the threadpool now resides in its own module file.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home