Project Ideas

There are plenty of opportunities for improving WebDSL and extending its scope. This page lists some ideas for possible Summer of Code projects, but this is by no means an exhaustive list. If you are interested in working on WebDSL this Summer, please contact EelcoVisser or any other member of the WebDSL team. You can also reach us at the webdsl@st.ewi.tudelft.nl mailinglist, or irc.freenode.net#webdsl IRC channel.

Back-ends

Develop a back-end for an alternative web programming platform. In particular, it would be good to have back-ends for PHP and .NET.

WebDSL currently generates Java SEAM and JSF code, which limits the use of WebDSL applications only to those who run a Java application server, such as JBoss. A PHP or .NET back-end would allow WebDSL applications to be deployed also on Microsoft platforms or on any host that supports PHP.

WebDSL consists of a core language and a number of abstractions on top of that. The core language is relatively low-level and close to the technology used to implement the application. The abstractions are higher-level constructs such as the templating system and access control. These abstractions are all translated to the WebDSL core language, which is relatively compact. Therefore it should be relatively straight-forward to reimplement this WebDSL core language back-end using other technologies, such as PHP and .NET.

Webservice Extension

The only source of data in WebDSL applications, currently, is the SQL database. It would, however, be interesting to be able to use external sources of data, such as those exposed through web services. Also, it would be useful to allow WebDSL applications to expose a web service API themselves.

It would be interesting to come up with a generic solution to this problem, so that not only SOAP/WSDL services would be supported, but also RESTful services with XML or JSON. There are a number of ways to approach this problem. One way is to step in at the XML-level and essentially parse and generate XML documents that are resp. retrieved and posted to some webservice. Another approach would be to assume there exists some mapping from WebDSL functions and data structures to web service methods and data structures and operate on that level. These mappings could be derived from WSDL or WADL documents.

Using these extensions it would be possible to retrieve pictures from Flickr, contacts from Google’s Contact API, retrieve videos from YouTube and post messages to Twitter, for instance. An application of exposing web service APIs would be to let the WebDSL application purely function as a server back-end, where the application front-end is implemented in a desktop application or in the browser using Google Web Toolkit.

Entity Versioning

To implement versioning on some entity, for instance a wiki page, currently you have to extend the application’s data model. For instance:

    entity Page {
      title    :: String
      content  :: WikiText
      previous -> PageDiff
      modified :: Date
      version  :: Int
      author   -> User
    }

    entity PageDiff {
      page     -> Page
      next     -> PageDiff
      title    :: String
      patch    :: Patch     // patch to create content of this version from next
      created  :: Date
      previous -> PageDiff
      date     :: Date
      author   -> User
      version  :: Int
    }

However, versioning of data is something that we would like direct support for in WebDSL, so that you can simply mark an entity as “versioned”, meaning that all old versions of an entity instance are kept in the database and can be rolled back. Subversion can be used as a inspiration here: a revision number that represent the entire state of the database at a certain point, a trunk version and branches that can later be merged back into the trunk. This feature can enable a lot of other features at a later stage of the WebDSL project, such as long-running transactions.

Interaction with “native” code

Not everything can be modeled in WebDSL, therefore it is sometimes necessary to use a “native” API, i.e. a Java library (when using the Java back-end).

Currently any kind of use of existing Java libraries has to happen through a built-in WebDSL construct, i.e. it has to become part of the language itself. This means that every time you need a piece of Java API not already available in WebDSL, you have to extend the generator, which, of course, is tedious.

To make this simpler, the WebDSL language would have to be extended to define WebDSL mappings to native (Java) APIs. Some pseudo code:

    external entity Random -> class java.util.Random {
      function setSeed(seed : Int) -> void setSeed(long seed);
      function nextInt() : Int -> int nextInt();
      function nextDouble() : Double -> double nextDouble();
    }

Which “promotes” a native Java library class to a regular WebDSL entity (in this case) and can be used in WebDSL code:

    var r : Random := Random {};
    someEntity.randomNumber := r.nextInt();

Screenscraping

When you do research on the web you often come across interesting information that you want to keep somewhere. However, saving the entire page is not really an ideal solution because you’re only interested in certain information and would later like to be able to query this information.

For instance, when doing research for a paper it often useful to scrape some information about papers you come across on scientific websites, such as IEEE, Springer link, ACM DL and post that to some other website, for future reference.

The idea of this project is to implement pieces of client-side JavaScript code that would extract pieces of relevant information from a certain web page and post those to some (WebDSL) web application to be stored and queried later. These “scrapers” will be specific for a certain website (such as Springer link), but will work for every page containing a certain type of data item (such as a paper) on the site. Once you have scrapers for the major sites in question, storing such data items becomes as easy as clicking a bookmark button in your browser.

Project Ideas