Quick minutes of last Web Design feast during TOOLS 2012 in Prague

[Jocelyn Fiat]

Hi all,

The 30th of May 2012, we had a one-day meeting on the current Eiffel Web Framework.

We had some discussion on specific points such as

- response (req: WSF_REQUEST): WSF_RESPONSE_MESSAGE 

  Is it necessary to provide two way to do almost the same "response (req): MESSAGE" and "execute (req, res)"?

  My answer was, the "response" interface is implemented using the "execute" interface, this is mainly to allow both visions, and the "response" way could be easier to learn.

  And this way we also benefit from the void-safety compilation (at least, the compilation will tell if the application forget to return a message).

  Now I also think this is important to keep the "execute (req, res)" interface, since it enables more possibilities, and also because it is used to implement the "response" design.

- replace "user" by "application" , since "user" would be the user of the service (web client, ... ) 

- WSF_RESPONSE_MESSAGE.send_to (..) had a comment such as "User should not use this directly"  

  First it was using --| ... which does not appear in flat format (or documentation)

  Then it was said .. do not use ... but it should also mention how this feature should be used ...

  Anyway, it appears the export to WSF_SERVICE is not necessary, so now, it is exported only to WSF_RESPONSE

  and the comment had been updated to 

-- Send Current message to `res'

--

-- This feature should be called via `{WSF_RESPONSE}.send (obj)'

-- where `obj' is the current object

- Question about why we need the genericity for the Router component 

   My answer is mainly, this is required by the code, since the ROUTER should be able to instantiate the related _CONTEXT class, and also call the `execute' or similar agent

   Now, I have in mind a different design which might enable the application to mix URI Template routing with regexp (not yet available), ... and other ...

   I will try to write down a note about this.

- Manifest string is evil 

   In the setup_router, we use manifest string to precise the request methods such as <<"GET", "POST">>

   this is considered evil, we should rather use available string constants, or find a way to precise the methods without any risk of typo

   Now, we should also allow custom request methods, since this is accepted with HTTP protocol.

- recent changes in WSF_STRING are not good 

   I added html_encoded_string  to WSF_STRING, but this is bad, since WSF_STRING has not specific relation with HTML, or XML, or JSON, or ... so this will be removed

   and probably added into WSF_HTML_PAGE_RESPONSE for instance to help user

- WSF_STRING.name and .string ... are not standard

   Suggestion either use

   `name' and `value'     or `key' and `item'

   I prefer `name' and `value' , what about you?

------------------------------

- Marco Piccioni also presented his tutorial for ABEL (persistent solution), he got some interesting feedback and suggestion

------------------------------

- Group-S presented quickly how they use EWF, they talked about the "filter" design, which should be included into EWF after the first release

And they also express their feeling about including non-void-safe component into EWF, mainly to tell people there are component on top of EWF (even if not yet void-safe).

The EWF is really meant to be a common framework to build component on top of it, so yes this is the goal to have more components availables.

However I don't think the EWF project should integrate all libraries, this should remain small, and in addition, if we include non-void-safe code, the whole project would become non void-safe, and this would be bad, since void-safe application could not use the framework as it is.

So I think we should 

   - keep EWF small enough, and fully void-safe

   - create a new repository to welcome or reference any components built on top of EWF, and this could include non void-safe code in a specific place. 

       With the goal to convert this code to void-safe.

But yes, the FastCGI connector made by Berend should have a place, so that people can use it for their project if needed.

--------------------------

Otherwise, after the workshop, I realized

1) during recent tests involving unicode, I realized the WSF_STRING was not handling in any case correctly the decoding unicode parameters.

    Sometimes it is html encoded as well, mixed with UTF8 .. and urlencoded, so we need to work on this and get it fixed as soon as possible.

2) about concurrency, currently if you build a service using the Router, you maybe initialize the router for each thread, so depending on the underlying connector, this could be improved.

    So, after the first release is done, this is one part we should also focus on.

    In relation to that, we should also improve the Eiffel Web Nino to support persistent connection, and better concurrency  (pool of thread, and pool of SCOOP processor)

    This way we get a better server written in Eiffel, and we can also test the application with different concurrency designs

-------------------------

For the future ...

As said during the workshop, we should also focus on REST , Hypermedia API, HATEOS, HAL, Collection/Json ... since this is topic in progress for any techno, and Eiffel can play an important role here.

So we will start building a Graphviz server built following those key designs (REST, hypermedia API, ...) to experiment those notions, and from this work, we'll try to abstract and provide library and tool to build easily goot RESTful API.

In background, I will be working as well on Google API and others, so that user can start having fun with Eiffel on the web.

As a conclusion, 

The workshop was interesting, maybe more for the before/after discussions rather than during the meeting itself.

We were not able to have an acceptable Google Hangout web meeting ... WiFi was vey unstable, sorry about that.

We should get more users, Eiffel users and maybe students as well which is always great to get feedback, and also contributions.

About contribution, I am glad to see that Group-S is contributing more and more, and I am confident that soon we'll get a nice ecosystem on top of EWF.

To continue this projet, we'll try to have a web meeting every 2 weeks.

Unless you feel this is too much or not enough.

And for any user, be sure that you will get any help needed from our team.

I personally thank all contributors of this project, all users, and in advance all futur users :D

Let's keep the good work.

-- Jocelyn

ps: I will share the slides very soon

[Jocelyn Fiat]

I forgot about one point not really discussed during the workshop.

We should try to find a fancy name, because EWF is not sexy

We should be able to talk about   "Foobar, the Eiffel Web Framework" and then as short "Foobar"

Of course "Foobar" is not a serious suggestion.

Any idea?

Other framework, not always with sexy names neither has  django, rails, php, symfony, web2py

I let any of you think about that, if we don't find any thing, let's keep "Eiffel Web Framework"

-- Jocelyn