Hi - See below.
On 3/7/16, 11:19 AM, "Deepankar Tyagi" <[email protected]> wrote: >Hi everyone, > >I am a Computer Science student at undergrad level and would love to >contribute to either of projects mentioned below. > > >I am currently in the process drafting the proposal and would be grateful >for any help in clearing grey areas. > > >Based on guidance and feedback, I plan to submit one proposal out of >these two topics. > > >The entire mail is an effort to seek help in defining scope, goals of >project and timeline more clearly. > > >#1 Demos > web server in chapel >Prior (relevant) experience : >My last year GSoC project involved porting libevent to a new platform >(full details about the same can be seen at https://deepankar.io/gsoc ) >during which I became acquianted > with libevent and improved upon the understanding of sockets/netwrok >programming. >I have never written a web server but have been ardent user of same in >various capabilities. This sounds like pretty good background for this project. > > >Questions and grey areas: > > >#1 Defining the rubric "simple" in "simple web server" more tangibly, one >of the most difficult task (for me) is coming up with a clear timeline. >As per my understanding, a simple web server gives at least following >capabilities > > >* If a url is mapped to directory then show the list of directory >content . and if the user clicks on non-executable file then it must be >downloaded. >* Executing scripts (of chapel) when url pointing to them is called. >* Executing scripts of other language with their respective >interpreters php-cgi, system exec etc (there will be likely a new process >per script) I wouldn't expect to support any scripting at all in a "simple web server". A "simple web server" doesn't even need necessarily to be HTTP complaint; it could serve something similar to HTTP. Of course it would be best if it actually served HTTP. Similarly directory listing is an optional feature for a web server. I'd list the requirement more like this: * Given a URL in a GET request, the web server responds to the GET request with the corresponding file >* Implementation must leverage chapel 'unique' capabilities. I view as this one as the main point of the project. Another way to put it is: * the web server should be written in a way that makes use of Chapel's tasks * the web server should handle very many independent connections at once >Inviting comments on above listed points, what should be added/modified ? > > >#2 Should the implementation focus on ipv4 and 6 both or I can focus on >ipv4 only at first. ( I am not entirely sure if this is even a valid >question) If you are clever with using only the proper library routines, it's not very hard to support both at once. That said, I'd focus on whatever you have easy access to first. For me, that would be v4. >#3 Do mentors have preferred library among libevent, libev, libuv etc. I think an initial task for this project would be to help us understand why we should use one over the others. I'm personally interested in libuv because it has the potential to help with Windows support in a way that the other libraries do not. Other than that, no preference. I'd expect a person doing this project to spend e.g. 1 week gathering information about the options and discussing them with their mentor/the Chapel developers. >#4 Should the calls be blocked or unblocked or both should be supported ? I'd like this project to demonstrate writing Chapel code that looks like it is using blocking calls, but where in reality it is implemented with non-blocking calls and task switching. > > > > >#2 Runtime > Reporting stack traces on halt >Prior (relevant) experience : >None as an implementor. Only as a user of various languages with this >capability. > > >Questions and grey areas: > > >Most likely the pace of implementation will increase(change) in >non-linear fashion, ie later half after gsoc-midterm will be more >productive in terms of code commits. >However I am confused what must be reasonable deliverables by >gsoc-midterm for this project since "investigation phase" may be finished >quickly or may take time. >I will be grateful for any suggestion for deliverables by gsoc-midterms > > > > >Lastly, >What would be preferred means to see/get progress reports, interactions >and preferred frequency of the same ? (I don't currently have good answers to these questions). > >and >Assuming I am interested in both of them with equal priority, which >project would mentor(s) recommend submitting proposal for ? It seems that your personal background is better for the web-server project, so if that is interesting to you that's the one I'd recommend you apply to. Cheers, -michael > > >Apologies for the long and probably irrelevant mail. > > >Some hyperlinks >Github <https://github.com/codebuff> || Linkedin ><https://www.linkedin.com/in/codebuff> || deepankar.io ><https://deepankar.io/> > > > >Best Regards. > > >Deepankar Tyagi > > > > > > > > > > > > > > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
