1459 replies to this topic

[bacicciosat]

Ok i think it is time to try to work to a common plugin
I have started OpenWebif.
This is not my project but our project. It is a long work but we have not hurry.
I have not intention to coordinate or to manage, everyone have to feel free to contribute in everyway.
Till now we have only the server starting and listening on port 8080 for static files in the folder: /usr/lib/enigma2/python/Plugins/Extensions/OpenWebif/www/html
We have only an example html template there.
The next things to do i think that are:
to implement Authentication
to complete Configuration
to choose a layout


The server is listening on port 8080 to avoid conflicts with webinterface so you can test.
For tests use folder: /usr/lib/enigma2/python/Plugins/Extensions/OpenWebif

[joseb]

Something is already listening op port 8080 on my et5000 and ET9000, perhaps the old webinterface:

netstat -tulpn

 
tcp	    0	  0 0.0.0.0:80			  0.0.0.0:*			   LISTEN	  415/enigma2
tcp	    0	  0 0.0.0.0:8080		    0.0.0.0:*			   LISTEN	  415/enigma2

Maybe choose another port? 8888?

[bacicciosat]

Don't worry. 8080 is just an example.
The port can be set in the range 1 - 65535
Of course if/when the plugin will be completed the port will be settable and the default value will be 80.
But it is a long long way.

[hemertje]

i think it's better to start a new topic for each new or existing plugin to discuss

[blzr]

well, with default 8080 port it gives nice GSOD here on OpenPLi

twisted.internet.error.CannotListenError: Couldn't listen on any:8080: [Errno 125] Address already in use.

BUT after manual change of the port >>> see the screenshot
you know what they say: "even the longest way starts with the first step"
keep it up!

Attached Files

•  Screenshot-3.png   157.81KB   815 downloads

Edited by blzr, 9 October 2011 - 19:30.

[bacicciosat]

Ok. example port changed

[skaman]

Good.. openwebif is a great idea and i really like blzr's screenshot

From my point of view we have to consider two things:
- keep a compatibility with apis of original webif (as described here: http://wiki.dbox2-tu...a2:WebInterface). At least the more important apis so the existing desktop tools could keep to communicate with the new web if.
- consider a compatibily with smartphones and tablets! If i try to use the original webif with an iphone or an ipad is the end!!! The graphical layout is unusable on that kind of devices and the javascript code is too heavy. I never known nothing who work so slower on that devices! I never tested it but i think the same problem exist on android based devices.

[dAF2000]

Would you like a specific thread here in 3rd party development for the openwebif? I can create one for you and move the posts about openwebif to that thread.

[bacicciosat]

Maybe later if it will get off the ground.

[skaman]

@bacicciosat
if there's no rush i want to do something on web if project. I hope to start to write some code next week.

[bacicciosat]

@bacicciosat
if there's no rush i want to do something on web if project. I hope to start to write some code next week.

It would be nice skaman. There is not rush.
There are many things to talk about.
First of all: Why another webif ? Do we think that the current webif could be made better or we simply want a free webif because of license problems ?
And what approach we think is better ?
I took a glance to the current e2 webif code and i have to admit that is a really good work and i am not sure it could be made better than this.
But i don't like the approach it is used. I don't like the large use of javascript functions to mix python and output code and i am not sure that it is the best idea for performance to use the e2 renderer engine with xml formatted templates to produce final html code. It seems to me a bizare long way. But maybe there is not a better solution.Twisted web provide a builtin template system (in xml too) but i have to admit that it seems too much more bizare if possible
Another solution could be to use directly python code final files that can work like WSGI applications or antoher one is to use a framework.
But i am a "php" lover so i have not found yet a solution that i can like.
For now i am only playing with twisted web to explore the possible scenarios.

[skaman]

It would be nice skaman. There is not rush.
There are many things to talk about.
First of all: Why another webif ? Do we think that the current webif could be made better or we simply want a free webif because of license problems ?

I think both.. a complete GPL webif would be nice... but i think we can do something better also from point of view of code.
Obviously "better" many times is a personal a point of view!

And what approach we think is better ?
I took a glance to the current e2 webif code and i have to admit that is a really good work and i am not sure it could be made better than this.
But i don't like the approach it is used. I don't like the large use of javascript functions to mix python and output code and i am not sure that it is the best idea for performance to use the e2 renderer engine with xml formatted templates to produce final html code. It seems to me a bizare long way. But maybe there is not a better solution.Twisted web provide a builtin template system (in xml too) but i have to admit that it seems too much more bizare if possible
Another solution could be to use directly python code final files that can work like WSGI applications or antoher one is to use a framework.
But i am a "php" lover so i have not found yet a solution that i can like.
For now i am only playing with twisted web to explore the possible scenarios.

I'm not a web developer... i did something in the past but my experiences are limited (so i could be wrong)
Personally i don't disagree to use xml data and ajax technologies inside the web if. But i have some doubt on actual webif:
- why a so complex work to make an xml output? isn't more simple (and easy to maintain) make a single .py module for every "webif api" and use the "xmlgenerator" provided by sax?
- why don't use a third party framework on client side? there are thousand of different frameworks online. And many of them are stable, lightweight, cross browser, ready for mobile devices and easy to use. We need only to choose one.
- is it really necessary use ajax for everything? i agree with ajax but only for improve the user experience... (for example navigate inside channels or epg without refresh the browser). I think there is a compromise in the middle. We can use ajax only when necessary (for example epg navigation) but provide a simple html for other things (for example timers list?)

I haven't yet played so much with twisted... there is any way to mix static and dynamic contents? for example php use <?php ?> tags to embed code in an html content without use thousand of prints.

[bacicciosat]

Ajax is necessary for performance speed up to not reload static contents of the pages.
But there is many javascript code (no Ajax) and functions that i think could be bypassed simply with a better use of python.
What we really need is to choose a good approach to produce dynamic content.

This is an exaple of template using in twisted web, but i am not sure to like it.
http://twistedmatrix...-templates.html

Edited by bacicciosat, 15 October 2011 - 08:46.

[Sjaaky]

xml is a definite no-go for me. json is the way to go.
ajax is handy for loading channel lists and such. But in the current webif, it is used everywhere. With the big disadvantage that the url in the addressbar doesn't match what you see on screen. For example, if you want to refresh a screenshot, you can not press f5. You have to click 'screen shot' again, which is much harder.

I've already created a simple bouquetlist channellist overview. It works with static html files, some javascript and a python function generating json. I will try to integrate it this weekend.

[bacicciosat]

About to use plain python or frameworks to render dynamic content it seems that the best way is simply string template method:

 
NAME = 'name'
 
 
def render1():
	template = "<p>Hello %s!</p>"
	return template % NAME
 
 
def render2():
	from string import Template
	template = Template("<p>Hello ${name}!</p>")
	return template.substitute(dict(name=NAME))
 
 
def render3():
	from mako.template import Template
	template = Template("<p>Hello ${name}!</p>")
	return template.render(name=NAME)
 
 
def render4():
	from genshi.template import MarkupTemplate
	tmpl = MarkupTemplate('<p>Hello $name!</p>')
	stream = tmpl.generate(name=NAME)
	return stream.render('xhtml')
 
 
def render5():
	from jinja2 import Template
	template = Template('<p>Hello {{ name }}!</p>')
	return template.render(name=NAME)
 
 
if __name__ == '__main__':
	num = int(sys.argv[1])
	print globals()['render%d' % num]()
	raw_input('Press Enter...')

Memory consumption Results:

Results:
Method RSS (kB)
standard formatting 4988 string.template 5020 Jinja2 7188 Genshi 7388 Mako 9148

Edited by bacicciosat, 15 October 2011 - 09:37.

[Sjaaky]

I agree.

[bacicciosat]

I've already created a simple bouquetlist channellist overview. It works with static html files, some javascript and a python function generating json. I will try to integrate it this weekend.

Great !

[MiLo]

If you like PHP, there's also PSP (Python Server Pages), which follows the same pattern of mixing code and HTML markup. And it's blazingly fast, because the templates can be "compiled" into python modules (both runtime for developing on the box, and compile time too so users get a fast ).

I think is quite possible to integrate PSP into the enigma2 reactor, so that you can directly access all enigma2 functionality from any template (or module used by it).

The box won't have to parse XML or so for every request, so it will run faster than anything you've seen so far

[bacicciosat]

Uhmm Milo,
it seems to me that PSP is a part of mod-python that is a module for Apache.
If it is so i am not sure that is a good idea to add Apache. We are working on twisted web that is already included in our image.
Or am i wrong ?

[MiLo]

The PSP part can be separated, so it just runs in the Python interpreter in enigma and uses twisted.web for serving the pages and handling requests. The rest of mod_python deals with Apache internals, we don't need that.

There are also some separate PSP modules around on the web, which just deal with the templates. The basis of PSP templates is that you can "compile" it by simply changing anything that's not python code into a write call. Writing a working PSP compiler in python shouldn't take more than an afternoon of bad weather.

<body>

 
<%=hello()%>
</body>

would compile into something like this:

def handle(req):
    req.write("""<body>
""")
    req.write(hello())
    req.write("""
</body>
""")