Ufront for C# (and maybe Java)?

[cambiata]

(Maybe you mentioned something about this in your Haxe conf speech - I don't remeber...)

What about the possibility to compile Ufront for C# target? Are there std libs for C# present that would make this possible? Or - if not - could a Ufront/C# project be something that could speed up the C# std lib development? (Maybe a question for Caue...)

Not high in priority for me, but I'm right now involved in a C# .NET MVC project (first time!) and it would be great to show off the speed and elegance of Haxe to the other team members..! :-)

[jasononeil]

There is no unified sys.Web class (only neko.Web and php.Web, no love for Java or C#). There is an existing issue herehttps://github.com/HaxeFoundation/haxe/issues/1855. Caûe basically said:

"I agree with this, but it seems to me that another cross-platform Web API should be created instead. For example, the fact that the current Web API is static has bad implications on some web servers."

I think currently the sys.db.* Database classes also aren't availablehttp://api.haxe.org/sys/db/Manager.html .

In my talk I mentioned that I was content with the Neko target for now, but was interested in the NodeJS target if only for the wide range of libraries (for example, different database drivers, webkit emulators, etc). Ufront itself is quite modular (When I have a free week sometime I have a plan to re-implement it entirely on the client side!) so porting to C# or Java would be quite possible, if underlying support for the key system level features is there.

A useful task may actually be to map out what the dependencies would be if we were looking at a new target. Certainly sys.db.*, and sys.Web classes. I believe serialization, remoting, and general filesystem access should already be working.

I personally wouldn't be heavily invested in porting to these targets at the moment as Neko is meeting my needs (if I have scaling issues and these are promising faster speeds or more options though...) but I would try and be as helpful as possible in making it work, and I don't think the process would be too hard if somebody understood the underlying platform well enough to implement the necessary APIs.

Jason

On Fri, Jul 5, 2013 at 8:09 PM, Jonas Nyström notifications@github.comwrote:

(Maybe you mentioned something about this in your Haxe conf speech - I don't remeber...)

What about the possibility to compile Ufront for C# target? Are there std libs for C# present that would make this possible? Or - if not - could a Ufront/C# project be something that could speed up the C# std lib development? (Maybe a question for Caue...)

Not high in priority for me, but I'm right now involved in a C# .NET MVC project (first time!) and it would be great to show off the speed and elegance of Haxe to the other team members..! :-)

— Reply to this email directly or view it on GitHubhttps://github.com/ufront/ufront/issues/2 .

[cambiata]

Thanks for clarifying answer!

I'm a neko user too - I love it on the server side (compared to ex php experiences!). But at the time beeing I'm doing some development for MS Azure servers and C# implementation would be really cool!

But - for the current Ufront project I will be using neko on Ubuntu servers.

[jasononeil]

I imagine you would need to implement:

• Sys - already implemented in C#, I assume it's well tested
• haxe.* - already implemented in C#, again I assume it's well tested.
• cs.Lib - implemented, not sure if it has all the methods required from neko.Lib, it would be worth clarifying all methods that are actually required by ufront.
• sys.FileSystem - not implemented, but cs.system.io.File etc are, so may not be hard.
• sys.db.Connection - the rest are fairly well abstracted.
• cs.Web - see this issue
• Session handling - this is currently implemented per-platform by ufront, and relies on Web.getCookies() and Web.getParams() etc.

If you feel you have sufficient understanding of the underlying platform (or at least, a sense of adventure!) then implementing these classes, and then getting ufront to work, would probably be quite achievable. You may find Cauê quite helpful also.

(I am making the assumption that Azure servers operate in a similar way to other HTTP servers - a binary is executed and the output of Sys.print etc renders the web page, and some methods will let you set headers, read parameters etc. if this is not the case things may be more difficult. I have no idea...)

[jasononeil]

See also this NodeJS implementation of various Standard Library classes: https://github.com/dionjwa/nodejs-std

Just to prove it would be possible to begin implementing some of these from the outside, and maybe get them into the standard library later.

[cambiata]

Hmm, I try to avoid javascript..! :-) Never touched Node (maybe that's the reason still avoiding it..) But Franco mentioned the NodeJS ideas when UFront was really newly born, and your ideas about a client side implementation are just great..!

[jasononeil]

This may be easier than I previously thought...

For the ufront-mvc stuff, there are literally only 3 classes / interfaces that would have to be implemented per new platform (Links to the PHP implementation):

https://github.com/ufront/ufront-mvc/blob/master/src/php/ufront/web/context/HttpRequest.hx https://github.com/ufront/ufront-mvc/blob/master/src/php/ufront/web/context/HttpResponse.hx https://github.com/ufront/ufront-mvc/blob/master/src/php/ufront/web/session/FileSession.hx

We may find other subtle small differences (hopefully unit tests will help isolate them), but that is a pretty manageable list... and it wouldn't require the Web class to be refactored to avoid singletons as waneck suggested.

I still have no personal need to implement this (nor an understanding of java or CS server environments), but it's just shifted from "refactor everything" levels of difficulty to "sounds like an interesting weekend project" :)

[cambiata]

Oh, life is full of interesting weekends, isn't it! :-) This is not top priority, of course, but still it would be great for the Ufront Marketing Dept. guys..!

[tjrhodes]

This would be a really good thing to do, to have windows servers covered without using PHP would be great, and run faster than PHP by miles.

As Jones says, for the marketing guys on the top floor of Ufront towers it would be a big selling point covering more and more platforms...

On 31 July 2013 07:36, Jonas Nyström notifications@github.com wrote:

Oh, life is full of interesting weekends, isn't it! :-) This is not top priority, of course, but still it would be great for the Ufront Marketing Dept. guys..!

— Reply to this email directly or view it on GitHubhttps://github.com/ufront/ufront/issues/2#issuecomment-21841242 .

[jasononeil]

After talking to Cauê and looking at some tutorials, I've found that for Java, a basic servlet (that could be used with google app engine or similar) might look like this:

import java.io.IOException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class MyServlet extends HttpServlet {
    @Override
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}

From Google App Engine Docs

The classes we need to implement in ufront are quite similar, probably because ufront copies MVC, and MVC copies the Java stack.

Related docs:

• http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html
• http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html
• http://msdn.microsoft.com/en-us/library/system.web.httpresponse.aspx
• http://msdn.microsoft.com/en-us/library/system.web.httprequest.aspx

Cauê also has a branch where he has SPOD beginning to work with static targets, Java in particular. This means the java target could target any database supported by JDBC, not just MySQL / Sqlite