Marcos Pividori | 3 May 02:53 2013
Picon

Google Summer of Code Proposal - Communicating with mobile devices

Greetings,

I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project.

I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on.

To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM – It is a Spanish commented version because it was a project for my University, I will replace it for an English version in the next weeks)

To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices.

I would be really grateful if you could give me your opinion about this project and the proposal. I want some feedback in order to know if this would be a useful tool and what you would like to get out of it.

Communicating with mobile devices


Abstract

The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on.

The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily.

When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are:

   - Google Cloud Messaging (Android)

   - Apple Push Notification Service (iPhone / iPad)

   - Microsoft Push Notification Service (Windows Phone)

   - BlackBerry Push Service (BlackBerry)

   - Windows Push Notification Services (Windows 8)

   - etc.

Once we have this libraries, I will investigate the possibility of mainting a "back and forth" communication between a server and mobile devices and I will develop a library to handle this.


Motivation and expected benefits

I think this idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them.

Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner.

Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast).

This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed. Once the data is delivered, the application can be launched in the background to process it as needed.

This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available.

The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc.

As all the libraries to access to these services are developed in Java, I thought that it would be a good idea to offer an option to Haskell programmers. Taking advantage of the similarity of these services, I could develop a very adaptable library which fits the necessities for each one and at the same time offer an abstraction to the user.


Deliverables.


* An API library to build and send messages including:

   - GCM and a demo Android app.

   - APN and a demo iOS app.

   - Microsoft Push Notification Service (Windows Phone) and a demo app.

   - Documentation for all the code developed. Including the explantation on how to use the server

     library and how to try the demo apps.

 

* A library to handle a "back and forth" comunication between a server and mobile devices. Tools to mantain a state of the connection and manage with a lot of devices at the same time. A Yesod app example of the use of this library and a demo app for each OS (Android, iOS, Windows Phone, etc) to manage this communication.

 

* Optionally:

   - an API for communication through BlackBerry Push Service (BlackBerry).

   - an API for communication through Windows Push Notification Services (Windows 8).

 

Technical Considerations

In the developing of the APIs for the communication through Push Notifications, I will aim to develop a good abstraction and find the properties in common between the differents services in order to develope an customizable tool but at the same time with a common structure.

I want to let the user build messages and send these in a simple way following each protocol. Also, I will abstract the process of registering the devices in the server and let the user manage the different registrations behind a similar abstraccion.

To develop a “back and forth” comunication between a server and mobile devices, I will investigate the different possibilities of maintaining a state of the connection. It could be through the use of cookies stored by the clients or maintaining some extra information in the server which would enable it to identify the different connections and provide the appropiate services.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Conrad Parker | 3 May 04:21 2013

Re: Google Summer of Code Proposal - Communicating with mobile devices

On 3 May 2013 08:53, Marcos Pividori <marcospividori <at> gmail.com> wrote:
> Greetings,
>
> I am a Computer Science student from Argentina. I am interested in working
> this summer in a project related to Haskell for the Google Summer of Code. I
> have been discussing my idea with Michael Snoyman in order to have a clearer
> idea. Now, I would like to know the community interest in this project.
>
> I want to develop a server-side library in Haskell for sending push
> notifications to devices running different OS, such as Android, iOS, Windows
> Phone, BlackBerry, and so on.
>
> To pass a subject, I have recently worked with Yesod (a Web Framework based
> in Haskell) developing a server to comunicate with Android-powered devices
> through Google Cloud Messaging. (It is available:
> https://github.com/MarcosPividori/Yesod-server-for-GCM – It is a Spanish
> commented version because it was a project for my University, I will replace
> it for an English version in the next weeks)
>
> To develop this project, I have read a lot about this service and Yesod
> libraries, and I developed two programs, a server written in Haskell and an
> Android application for mobile phones. Also, I developed an EDSL to write
> programs which exchange information with the devices.
>
> I would be really grateful if you could give me your opinion about this
> project and the proposal. I want some feedback in order to know if this
> would be a useful tool and what you would like to get out of it.
>
> Communicating with mobile devices
>
>
> Abstract
>
> The aim of this project is to develop a server-side library in Haskell for
> sending push notifications to devices running different OS, such as Android,
> iOS, Windows Phone, BlackBerry, and so on.
>
> The fact is that every company is developing Push Notification services, and
> these are very similar. Then, I want to find the fundamental concepts to
> construct a library which enable to configure the options for the different
> services and send messages easily.
>
> When I say they are very similar, I refer to the fact that they all are
> asynchronous, best-effort services that offers third-party developers a
> channel to send data to apps from a cloud service in a power-efficient
> manner. The most popular are:
>
>    - Google Cloud Messaging (Android)
>
>    - Apple Push Notification Service (iPhone / iPad)
>
>    - Microsoft Push Notification Service (Windows Phone)
>
>    - BlackBerry Push Service (BlackBerry)
>
>    - Windows Push Notification Services (Windows 8)
>
>    - etc.
>
> Once we have this libraries, I will investigate the possibility of mainting
> a "back and forth" communication between a server and mobile devices and I
> will develop a library to handle this.
>
>
> Motivation and expected benefits
>
> I think this idea would be very useful because it will allow all Haskell
> developers to open to a new world of mobile devices and to build useful
> programs/services that interact with them.
>
> Pushing data to smartphones provides users with instant access to desired
> updates as they happen, such as news and weather, sports scores, stock
> prices and other time-sensitive content. The push services provide an
> efficient way to quickly push timely information updates to many smartphones
> at once, in a centrally managed and controlled manner.
>
> Generally, you can also be very selective in who you send information to,
> including individual customers or many customers (multicast).
>
> This services minimizes the impact on the smartphones battery life. Instead
> of actively checking for new data, the applications can remain closed. Once
> the data is delivered, the application can be launched in the background to
> process it as needed.
>
> This processes offer an alternative to other less efficient methods, such as
> polling, where a device regularly polls an application server to see if new
> content is available.
>
> The main differences between the services, refer to details as: the maxim
> payload length, the quality of service, queueing the messages or not, and
> the time limit for this, the way the messages are handled in the devices,
> etc.
>
> As all the libraries to access to these services are developed in Java, I
> thought that it would be a good idea to offer an option to Haskell
> programmers. Taking advantage of the similarity of these services, I could
> develop a very adaptable library which fits the necessities for each one and
> at the same time offer an abstraction to the user.
>
>
> Deliverables.
>
>
> * An API library to build and send messages including:
>
>    - GCM and a demo Android app.
>
>    - APN and a demo iOS app.
>
>    - Microsoft Push Notification Service (Windows Phone) and a demo app.
>
>    - Documentation for all the code developed. Including the explantation on
> how to use the server
>
>      library and how to try the demo apps.
>
>
>
> * A library to handle a "back and forth" comunication between a server and
> mobile devices. Tools to mantain a state of the connection and manage with a
> lot of devices at the same time. A Yesod app example of the use of this
> library and a demo app for each OS (Android, iOS, Windows Phone, etc) to
> manage this communication.
>
>
>
> * Optionally:
>
>    - an API for communication through BlackBerry Push Service (BlackBerry).
>
>    - an API for communication through Windows Push Notification Services
> (Windows 8).
>
>
>
> Technical Considerations
>
> In the developing of the APIs for the communication through Push
> Notifications, I will aim to develop a good abstraction and find the
> properties in common between the differents services in order to develope an
> customizable tool but at the same time with a common structure.
>
> I want to let the user build messages and send these in a simple way
> following each protocol. Also, I will abstract the process of registering
> the devices in the server and let the user manage the different
> registrations behind a similar abstraccion.
>
> To develop a “back and forth” comunication between a server and mobile
> devices, I will investigate the different possibilities of maintaining a
> state of the connection. It could be through the use of cookies stored by
> the clients or maintaining some extra information in the server which would
> enable it to identify the different connections and provide the appropiate
> services.

Hi Marcos,

I really like this project, I think it will be very useful.

You've listed a lot of deliverables. In what order would you plan to
do things, and what deliverables would you consider essential to call
the project a success?

It sometimes happens with GSoC projects that some random task takes
longer than expected, or something in real-life delays progress. To
ensure success, you could make a timeline with all the essential
deliverables done about 60% of the way through, and the rest of the
time for bonus deliverables and polishing.

cheers,

Conrad.
Kristopher Micinski | 5 May 04:46 2013
Picon

Re: Google Summer of Code Proposal - Communicating with mobile devices

Marcos,

Great to see you've revised a copy of this.  I've often felt that push
communication to devices has a very continuation-y flavor, and I think
having something in a web framework to express this would be great.

It looks like a large part of your time may be spent developing demo
apps, which is too bad, since ideally (for a Haskell project) you'd
want to spend as much time as possible writing in Haskell :-).
Perhaps you could write a fleshed out demo app for one environment
(iOS, Android, etc..) and then shallower examples for the rest.  (In
theory of course, you don't even need to write sample apps for most
platforms, since the push API should be an abstraction layer above
that...).

Should this project make it through to be one of Haskell's GSOC
projects, I'd be happy to chat with you about your development.

Kris

On Thu, May 2, 2013 at 8:53 PM, Marcos Pividori
<marcospividori <at> gmail.com> wrote:
> Greetings,
>
> I am a Computer Science student from Argentina. I am interested in working
> this summer in a project related to Haskell for the Google Summer of Code. I
> have been discussing my idea with Michael Snoyman in order to have a clearer
> idea. Now, I would like to know the community interest in this project.
>
> I want to develop a server-side library in Haskell for sending push
> notifications to devices running different OS, such as Android, iOS, Windows
> Phone, BlackBerry, and so on.
>
> To pass a subject, I have recently worked with Yesod (a Web Framework based
> in Haskell) developing a server to comunicate with Android-powered devices
> through Google Cloud Messaging. (It is available:
> https://github.com/MarcosPividori/Yesod-server-for-GCM – It is a Spanish
> commented version because it was a project for my University, I will replace
> it for an English version in the next weeks)
>
> To develop this project, I have read a lot about this service and Yesod
> libraries, and I developed two programs, a server written in Haskell and an
> Android application for mobile phones. Also, I developed an EDSL to write
> programs which exchange information with the devices.
>
> I would be really grateful if you could give me your opinion about this
> project and the proposal. I want some feedback in order to know if this
> would be a useful tool and what you would like to get out of it.
>
> Communicating with mobile devices
>
>
> Abstract
>
> The aim of this project is to develop a server-side library in Haskell for
> sending push notifications to devices running different OS, such as Android,
> iOS, Windows Phone, BlackBerry, and so on.
>
> The fact is that every company is developing Push Notification services, and
> these are very similar. Then, I want to find the fundamental concepts to
> construct a library which enable to configure the options for the different
> services and send messages easily.
>
> When I say they are very similar, I refer to the fact that they all are
> asynchronous, best-effort services that offers third-party developers a
> channel to send data to apps from a cloud service in a power-efficient
> manner. The most popular are:
>
>    - Google Cloud Messaging (Android)
>
>    - Apple Push Notification Service (iPhone / iPad)
>
>    - Microsoft Push Notification Service (Windows Phone)
>
>    - BlackBerry Push Service (BlackBerry)
>
>    - Windows Push Notification Services (Windows 8)
>
>    - etc.
>
> Once we have this libraries, I will investigate the possibility of mainting
> a "back and forth" communication between a server and mobile devices and I
> will develop a library to handle this.
>
>
> Motivation and expected benefits
>
> I think this idea would be very useful because it will allow all Haskell
> developers to open to a new world of mobile devices and to build useful
> programs/services that interact with them.
>
> Pushing data to smartphones provides users with instant access to desired
> updates as they happen, such as news and weather, sports scores, stock
> prices and other time-sensitive content. The push services provide an
> efficient way to quickly push timely information updates to many smartphones
> at once, in a centrally managed and controlled manner.
>
> Generally, you can also be very selective in who you send information to,
> including individual customers or many customers (multicast).
>
> This services minimizes the impact on the smartphones battery life. Instead
> of actively checking for new data, the applications can remain closed. Once
> the data is delivered, the application can be launched in the background to
> process it as needed.
>
> This processes offer an alternative to other less efficient methods, such as
> polling, where a device regularly polls an application server to see if new
> content is available.
>
> The main differences between the services, refer to details as: the maxim
> payload length, the quality of service, queueing the messages or not, and
> the time limit for this, the way the messages are handled in the devices,
> etc.
>
> As all the libraries to access to these services are developed in Java, I
> thought that it would be a good idea to offer an option to Haskell
> programmers. Taking advantage of the similarity of these services, I could
> develop a very adaptable library which fits the necessities for each one and
> at the same time offer an abstraction to the user.
>
>
> Deliverables.
>
>
> * An API library to build and send messages including:
>
>    - GCM and a demo Android app.
>
>    - APN and a demo iOS app.
>
>    - Microsoft Push Notification Service (Windows Phone) and a demo app.
>
>    - Documentation for all the code developed. Including the explantation on
> how to use the server
>
>      library and how to try the demo apps.
>
>
>
> * A library to handle a "back and forth" comunication between a server and
> mobile devices. Tools to mantain a state of the connection and manage with a
> lot of devices at the same time. A Yesod app example of the use of this
> library and a demo app for each OS (Android, iOS, Windows Phone, etc) to
> manage this communication.
>
>
>
> * Optionally:
>
>    - an API for communication through BlackBerry Push Service (BlackBerry).
>
>    - an API for communication through Windows Push Notification Services
> (Windows 8).
>
>
>
> Technical Considerations
>
> In the developing of the APIs for the communication through Push
> Notifications, I will aim to develop a good abstraction and find the
> properties in common between the differents services in order to develope an
> customizable tool but at the same time with a common structure.
>
> I want to let the user build messages and send these in a simple way
> following each protocol. Also, I will abstract the process of registering
> the devices in the server and let the user manage the different
> registrations behind a similar abstraccion.
>
> To develop a “back and forth” comunication between a server and mobile
> devices, I will investigate the different possibilities of maintaining a
> state of the connection. It could be through the use of cookies stored by
> the clients or maintaining some extra information in the server which would
> enable it to identify the different connections and provide the appropiate
> services.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
Marcos Pividori | 13 May 05:01 2013
Picon

Re: Google Summer of Code Proposal - Communicating with mobile devices

Hi, Thanks for your feedback! I have presented the proposal, and now I have to wait for a response.
I want to let you know that I have already replaced the code for an English version.
I hope it will be more useful now!
Thanks,
Marcos


2013/5/4 Kristopher Micinski <krismicinski <at> gmail.com>
Marcos,

Great to see you've revised a copy of this.  I've often felt that push
communication to devices has a very continuation-y flavor, and I think
having something in a web framework to express this would be great.

It looks like a large part of your time may be spent developing demo
apps, which is too bad, since ideally (for a Haskell project) you'd
want to spend as much time as possible writing in Haskell :-).
Perhaps you could write a fleshed out demo app for one environment
(iOS, Android, etc..) and then shallower examples for the rest.  (In
theory of course, you don't even need to write sample apps for most
platforms, since the push API should be an abstraction layer above
that...).

Should this project make it through to be one of Haskell's GSOC
projects, I'd be happy to chat with you about your development.

Kris

On Thu, May 2, 2013 at 8:53 PM, Marcos Pividori
<marcospividori <at> gmail.com> wrote:
> Greetings,
>
> I am a Computer Science student from Argentina. I am interested in working
> this summer in a project related to Haskell for the Google Summer of Code. I
> have been discussing my idea with Michael Snoyman in order to have a clearer
> idea. Now, I would like to know the community interest in this project.
>
> I want to develop a server-side library in Haskell for sending push
> notifications to devices running different OS, such as Android, iOS, Windows
> Phone, BlackBerry, and so on.
>
> To pass a subject, I have recently worked with Yesod (a Web Framework based
> in Haskell) developing a server to comunicate with Android-powered devices
> through Google Cloud Messaging. (It is available:
> https://github.com/MarcosPividori/Yesod-server-for-GCM – It is a Spanish
> commented version because it was a project for my University, I will replace
> it for an English version in the next weeks)
>
> To develop this project, I have read a lot about this service and Yesod
> libraries, and I developed two programs, a server written in Haskell and an
> Android application for mobile phones. Also, I developed an EDSL to write
> programs which exchange information with the devices.
>
> I would be really grateful if you could give me your opinion about this
> project and the proposal. I want some feedback in order to know if this
> would be a useful tool and what you would like to get out of it.
>
> Communicating with mobile devices
>
>
> Abstract
>
> The aim of this project is to develop a server-side library in Haskell for
> sending push notifications to devices running different OS, such as Android,
> iOS, Windows Phone, BlackBerry, and so on.
>
> The fact is that every company is developing Push Notification services, and
> these are very similar. Then, I want to find the fundamental concepts to
> construct a library which enable to configure the options for the different
> services and send messages easily.
>
> When I say they are very similar, I refer to the fact that they all are
> asynchronous, best-effort services that offers third-party developers a
> channel to send data to apps from a cloud service in a power-efficient
> manner. The most popular are:
>
>    - Google Cloud Messaging (Android)
>
>    - Apple Push Notification Service (iPhone / iPad)
>
>    - Microsoft Push Notification Service (Windows Phone)
>
>    - BlackBerry Push Service (BlackBerry)
>
>    - Windows Push Notification Services (Windows 8)
>
>    - etc.
>
> Once we have this libraries, I will investigate the possibility of mainting
> a "back and forth" communication between a server and mobile devices and I
> will develop a library to handle this.
>
>
> Motivation and expected benefits
>
> I think this idea would be very useful because it will allow all Haskell
> developers to open to a new world of mobile devices and to build useful
> programs/services that interact with them.
>
> Pushing data to smartphones provides users with instant access to desired
> updates as they happen, such as news and weather, sports scores, stock
> prices and other time-sensitive content. The push services provide an
> efficient way to quickly push timely information updates to many smartphones
> at once, in a centrally managed and controlled manner.
>
> Generally, you can also be very selective in who you send information to,
> including individual customers or many customers (multicast).
>
> This services minimizes the impact on the smartphones battery life. Instead
> of actively checking for new data, the applications can remain closed. Once
> the data is delivered, the application can be launched in the background to
> process it as needed.
>
> This processes offer an alternative to other less efficient methods, such as
> polling, where a device regularly polls an application server to see if new
> content is available.
>
> The main differences between the services, refer to details as: the maxim
> payload length, the quality of service, queueing the messages or not, and
> the time limit for this, the way the messages are handled in the devices,
> etc.
>
> As all the libraries to access to these services are developed in Java, I
> thought that it would be a good idea to offer an option to Haskell
> programmers. Taking advantage of the similarity of these services, I could
> develop a very adaptable library which fits the necessities for each one and
> at the same time offer an abstraction to the user.
>
>
> Deliverables.
>
>
> * An API library to build and send messages including:
>
>    - GCM and a demo Android app.
>
>    - APN and a demo iOS app.
>
>    - Microsoft Push Notification Service (Windows Phone) and a demo app.
>
>    - Documentation for all the code developed. Including the explantation on
> how to use the server
>
>      library and how to try the demo apps.
>
>
>
> * A library to handle a "back and forth" comunication between a server and
> mobile devices. Tools to mantain a state of the connection and manage with a
> lot of devices at the same time. A Yesod app example of the use of this
> library and a demo app for each OS (Android, iOS, Windows Phone, etc) to
> manage this communication.
>
>
>
> * Optionally:
>
>    - an API for communication through BlackBerry Push Service (BlackBerry).
>
>    - an API for communication through Windows Push Notification Services
> (Windows 8).
>
>
>
> Technical Considerations
>
> In the developing of the APIs for the communication through Push
> Notifications, I will aim to develop a good abstraction and find the
> properties in common between the differents services in order to develope an
> customizable tool but at the same time with a common structure.
>
> I want to let the user build messages and send these in a simple way
> following each protocol. Also, I will abstract the process of registering
> the devices in the server and let the user manage the different
> registrations behind a similar abstraccion.
>
> To develop a “back and forth” comunication between a server and mobile
> devices, I will investigate the different possibilities of maintaining a
> state of the connection. It could be through the use of cookies stored by
> the clients or maintaining some extra information in the server which would
> enable it to identify the different connections and provide the appropiate
> services.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
John Lato | 12 Feb 17:49 2009
Picon

Re: Google Summer of Code 2009

Johan Tibell wrote:
> On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa <felipe.lessa <at> gmail.com> wrote:
>> Do we already have enough information to turn
>> http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized
>> package? I think Iteratees may prove themselves as useful as
>> ByteStrings.
>
> I still haven't figured out what the "correct" definition of Iteratee
> would look like. The Iteratee code that Oleg wrote seems to have the
> structure of some kind of "two level" monad. I think that's the reason
> for the frequent occurrences of >>== and liftI in the code. There
> seems to be some things we yet have to discover about Iteratees.
>

I concur.  I've recently been involved with several discussions on
this topic, and there are some issues that remain.  The "two level
monad" part doesn't bother me, but I think the type should be slightly
more abstract and I'm not sure of the best way to do so.  IMO liftI is
used more because of Oleg's particular style of coding than anything
else.  I don't think it need be common in user code, although it may
be more efficient.

I think that, if a GSOC project were to focus on Iteratees, it would
need to look at issues like these.  I can't judge as to whether this
is an appropriate amount of work for GSOC, however simply packaging
and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely
of too small a scope.

John Lato
Gwern Branwen | 12 Feb 18:00 2009
Picon

Re: Re: Google Summer of Code 2009

On Thu, Feb 12, 2009 at 11:49 AM, John Lato <jwlato <at> gmail.com> wrote:
> Johan Tibell wrote:
>> On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa <felipe.lessa <at> gmail.com> wrote:
>>> Do we already have enough information to turn
>>> http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized
>>> package? I think Iteratees may prove themselves as useful as
>>> ByteStrings.
>>
>> I still haven't figured out what the "correct" definition of Iteratee
>> would look like. The Iteratee code that Oleg wrote seems to have the
>> structure of some kind of "two level" monad. I think that's the reason
>> for the frequent occurrences of >>== and liftI in the code. There
>> seems to be some things we yet have to discover about Iteratees.
>>
>
> I concur.  I've recently been involved with several discussions on
> this topic, and there are some issues that remain.  The "two level
> monad" part doesn't bother me, but I think the type should be slightly
> more abstract and I'm not sure of the best way to do so.  IMO liftI is
> used more because of Oleg's particular style of coding than anything
> else.  I don't think it need be common in user code, although it may
> be more efficient.
>
> I think that, if a GSOC project were to focus on Iteratees, it would
> need to look at issues like these.  I can't judge as to whether this
> is an appropriate amount of work for GSOC, however simply packaging
> and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely
> of too small a scope.
>
> John Lato

I agree. Just packaging and cabalizing something is likely not a
SoC-worthy project. (This is why the 'cabalize Wash' suggestion will
never make it, for example.) In general, cabalizing seems to be either
pretty easy (most everything I've cabalized) or next to impossible
(gtk2hs, ghc). The former are too trivial for SoC, and the latter
likely are impossible without more development of Cabal - at which
point it'd be more correct to call it a Cabal SoC and not a cabalizing
SoC.

--

-- 
gwern
Don Stewart | 12 Feb 18:12 2009

Re: Re: Google Summer of Code 2009

gwern0:
> On Thu, Feb 12, 2009 at 11:49 AM, John Lato <jwlato <at> gmail.com> wrote:
> > Johan Tibell wrote:
> >> On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa <felipe.lessa <at> gmail.com> wrote:
> >>> Do we already have enough information to turn
> >>> http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized
> >>> package? I think Iteratees may prove themselves as useful as
> >>> ByteStrings.
> >>
> >> I still haven't figured out what the "correct" definition of Iteratee
> >> would look like. The Iteratee code that Oleg wrote seems to have the
> >> structure of some kind of "two level" monad. I think that's the reason
> >> for the frequent occurrences of >>== and liftI in the code. There
> >> seems to be some things we yet have to discover about Iteratees.
> >>
> >
> > I concur.  I've recently been involved with several discussions on
> > this topic, and there are some issues that remain.  The "two level
> > monad" part doesn't bother me, but I think the type should be slightly
> > more abstract and I'm not sure of the best way to do so.  IMO liftI is
> > used more because of Oleg's particular style of coding than anything
> > else.  I don't think it need be common in user code, although it may
> > be more efficient.
> >
> > I think that, if a GSOC project were to focus on Iteratees, it would
> > need to look at issues like these.  I can't judge as to whether this
> > is an appropriate amount of work for GSOC, however simply packaging
> > and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely
> > of too small a scope.
> >
> > John Lato
> 
> I agree. Just packaging and cabalizing something is likely not a
> SoC-worthy project. (This is why the 'cabalize Wash' suggestion will
> never make it, for example.) In general, cabalizing seems to be either
> pretty easy (most everything I've cabalized) or next to impossible
> (gtk2hs, ghc). The former are too trivial for SoC, and the latter
> likely are impossible without more development of Cabal - at which
> point it'd be more correct to call it a Cabal SoC and not a cabalizing
> SoC.

Yes, "cabalising" was more of a priority when we only had 10 libraries :)

So in general, think hard about missing capabilities in Haskell:

    * tools
    * libraries
    * infrastructure

that benefit the broadest number of Haskell users or developers.

Another route is to identify a clear niche where Haskell could leap
ahead of the competition, with a small investment.

-- Don
Edward Kmett | 12 Mar 18:15 2010
Picon

Google Summer of Code 2010.

It is that time of year again; the Google Summer of Code is upon us!



Sign Up Information

If you are a student and want to sign up to make $4,500 for hacking on the code you love over the summer or are willing to help out as a mentor, now is the time to act. Please sign up by adding your name to the list at:

http://hackage.haskell.org/trac/summer-of-code/wiki/People2010

I have extracted an initial list of interested mentors from Malcolm's earlier inquiry to the cafe and have submitted our initial application to Google. A strong list of potential mentors and students will help bolster our case.

Our main wiki entry for the Summer of Code 2010 is now online:

http://hackage.haskell.org/trac/summer-of-code/wiki/Soc2010

If you are interested in applying as a student, here are some guidelines:

http://hackage.haskell.org/trac/summer-of-code/wiki/StudApply2010

The official deadline for student applications with Google is April 7th, but if you are interested please add your name to the People2010 page above, as soon as possible.

Interested in helping out, but not sure how?

There are a number of ideas that we've been collecting for projects available through the trac

http://hackage.haskell.org/trac/summer-of-code/report/1

and which have been collecting over time in a reddit:

http://www.reddit.com/r/haskell_proposals/top/

While the reddit is a great place to discuss proposals,  we had to choose one mechanism to supply Google with our ideas officially, so please submit proposals to the trac if you can think of something you like to work on, or which would be an appropriately beneficial project for a summer worth of work.

Helping Out Darcs

Haskell.org is going to continue to act as an umbrella organization covering darcs for the Summer of Code once more. If you are interested in helping them out, they also have a page full of project ideas as well:

http://wiki.darcs.net/GoogleSummerOfCode

Again, please submit proposals as tickets to the trac if you can think of something you'd like to work on.

More Information

Here are a bunch of relevant links that may be able to answer your questions:

Google's Summer of Code Homepage
Google's Summer of Code 2010 FAQ
Google's Summer of Code 2010 Timeline
Google's Summer of Code Wiki Knowledge Base

Of course, you can always feel free to email me or inquire on irc.freenode.net #haskell-soc or with the darcs folks over on #darcs for more information. If you don't have an IRC client, you can get there from: http://webchat.freenode.net

Thank you all very much and we look forward to another successful Summer of Code!

-Edward Kmett

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane