Hi all,
http://www.eweek.com/c/a/Linux-and-Open-Source/Apache-Brokeback-JCP-I-Wish-I...
We always never touched anything (at least since 2001) that was not clearly community driven and with a freesoftware licence.
I however now find myself in a rather strange position of having to use JAVA or something similiar for a particular project.
The reason is that we require tight state binding on the browser based UI interface.
Background: It is an interactive robot with its clone sitting on your desk and a browser interface. The browser is used for interaction. The clone can also be used for interaction - move the leg manually and the remote will move as well as update the params on the screen.
I don want to use a custom app for numerous reasons.
Any and all recommendations welcome.
On Sat, Nov 13, 2010 at 11:18 AM, jtd jtd@mtnl.net.in wrote:
Hi all,
http://www.eweek.com/c/a/Linux-and-Open-Source/Apache-Brokeback-JCP-I-Wish-I...
We always never touched anything (at least since 2001) that was not clearly community driven and with a freesoftware licence.
I however now find myself in a rather strange position of having to use JAVA or something similiar for a particular project.
how free is openjdk? at gnowledge lab we are using two of the educational packages that run on openjdk, geogebra and freemind?
-- GN
On Saturday 13 November 2010 11:23:20 Nagarjuna G wrote:
On Sat, Nov 13, 2010 at 11:18 AM, jtd jtd@mtnl.net.in wrote:
Hi all,
http://www.eweek.com/c/a/Linux-and-Open-Source/Apache-Brokeback-J CP-I-Wish-I-Knew-How-to-Quit-You-138152/
We always never touched anything (at least since 2001) that was not clearly community driven and with a freesoftware licence.
I however now find myself in a rather strange position of having to use JAVA or something similiar for a particular project.
how free is openjdk? at gnowledge lab we are using two of the educational packages that run on openjdk, geogebra and freemind?
OpenJDK has/had some closed parts. Hence it is supposed to be replaced with OpenJDK + IcedTea. This combo is supposed to be ok. As per the discussion below, it specifically addresses the binary parts and the of OpenJDK
http://help.lockergnome.com/linux/Sun-OpenJDK-Debian--ftopict462456.html
In particular the "Assembly Exception".
http://openjdk.java.net/legal/assembly-exception.html
Checking out OpenJDK + IcedTea details. Available on lenny. Any hints on toolkits?
I also found pyjamas (http://www.pyjs.org) interesting. Especially since this would work on my embedded targets.
-- GN
Hey jtd,
On 11/13/2010 11:18 AM, jtd wrote:
Hi all,
http://www.eweek.com/c/a/Linux-and-Open-Source/Apache-Brokeback-JCP-I-Wish-I...
We always never touched anything (at least since 2001) that was not clearly community driven and with a freesoftware licence.
I however now find myself in a rather strange position of having to use JAVA or something similiar for a particular project.
I am sorry but I didn't quite get the connection between the link you posted and your request ...beyond the fact that there is some trouble in Apache land over Java.
The reason is that we require tight state binding on the browser based UI interface.
What sort of client side state do you wish to maintain ? AFAIK, one is no longer bound to using Java for feature rich browser based applications. Javascript (in the macro sense that also includes jQuery, YUI, all of google's js stuff and the tons of ajax libraries that litter the web) is quite capable of turning the browser into a proper target platform for alternatives to most desktop based applications.
Background: It is an interactive robot with its clone sitting on your desk and a browser interface. The browser is used for interaction. The clone can also be used for interaction - move the leg manually and the remote will move as well as update the params on the screen.
Where will the main 'engine' for the robot run ? on the robot's controller ? In any case, for this use case you needn't touch java at all IMHO. All client side stuff can be done using javascript.
cheers, - steve
What sort of client side state do you wish to maintain ? AFAIK, one is no longer bound to using Java for feature rich browser based applications. Javascript (in the macro sense that also includes jQuery, YUI, all of google's js stuff and the tons of ajax libraries that litter the web) is quite capable of turning the browser into a proper target platform for alternatives to most desktop based applications.
Javascript is not an optimal solution in this use case.
Based on initial email of this thread, aim it to control a robot from browser based UI. This requires very low-latency communication between UI and device.
Request/Response model of JS is not suitable for this. Socket connections via Flex/ Flash would be tool of choice in current environment. Flex is open source and you can use open source flash player for UI. Flash integrated nicely with browser via JS interface.
Or you can use Flash/Flex just for communication and implement rest of UI in JS.
Same functionality can be achieved via Java Applets, but UI development is not a strength of Java (Swing).
-Shamit
On Sun, Nov 14, 2010 at 5:56 PM, Shamit Verma subs.linux.mum@vshamit.comwrote:
Flex is open source .......
It might not be in future. http://www.theregister.co.uk/2010/11/02/adobe_opensource/
With regards, Shirish Padalkar http://twitter.com/_Garbage_
On Sunday 14 November 2010 17:56:52 Shamit Verma wrote:
What sort of client side state do you wish to maintain ? AFAIK, one is no longer bound to using Java for feature rich browser based applications. Javascript (in the macro sense that also includes jQuery, YUI, all of google's js stuff and the tons of ajax libraries that litter the web) is quite capable of turning the browser into a proper target platform for alternatives to most desktop based applications.
Javascript is not an optimal solution in this use case.
Based on initial email of this thread, aim it to control a robot from browser based UI. This requires very low-latency communication between UI and device.
True.
Request/Response model of JS is not suitable for this. Socket connections via Flex/ Flash would be tool of choice in current environment. Flex is open source and you can use open source flash player for UI. Flash integrated nicely with browser via JS interface.
Flash is mpeg4 encoded which is patent encumbered by the finest patent trolls in the world. The decode licence expired recently, but was renewed a few weeks before that for a period TWO years. Further encoding for "commercial" purposes requires a mandatory licence. And the standards development body are amongst the best bunch of crooks one could aspire to be.
No way am I going to touch flash.
I dont know of "flex" like foss dev platform that uses vp8 or ogg-theora. Afaik there are none.
Or you can use Flash/Flex just for communication and implement rest of UI in JS.
Same functionality can be achieved via Java Applets, but UI development is not a strength of Java (Swing).
investigation continues..... mucking about the incomrehensible maize of frameworks.
Flash is mpeg4 encoded which is patent encumbered by the finest patent trolls in the world. The decode licence expired recently, but was renewed a few weeks before that for a period TWO years. Further encoding for "commercial" purposes requires a mandatory licence. And the standards development body are amongst the best bunch of crooks one could aspire to be.
No way am I going to touch flash.
You need not worry about any of these things by a simple tweak. use "just" the socket communication functionality of Flash.
Leave rest of the UI to JS. Its literraly one line of code for each API for that API to be exposed to JS.
So you can create a couple of classes that encapsulate socket communication. And expose those classes to JS. In that case you would not be using any patented functionality. And this would work with Open Source flash runtimes (VMs) that are not controlled by Adobe.
On the other hand, you can do the same things with Java too. I.e. develop the UI in JS and leave only socket communication to Java.
-Shamit
On Monday 15 November 2010 00:05:24 Shamit Verma wrote:
Flash is mpeg4 encoded which is patent encumbered by the finest patent trolls in the world. The decode licence expired recently, but was renewed a few weeks before that for a period TWO years. Further encoding for "commercial" purposes requires a mandatory licence. And the standards development body are amongst the best bunch of crooks one could aspire to be.
No way am I going to touch flash.
You need not worry about any of these things by a simple tweak. use "just" the socket communication functionality of Flash.
Leave rest of the UI to JS. Its literraly one line of code for each API for that API to be exposed to JS.
So you can create a couple of classes that encapsulate socket communication. And expose those classes to JS. In that case you would not be using any patented functionality. And this would work with Open Source flash runtimes (VMs) that are not controlled by Adobe.
On the other hand, you can do the same things with Java too. I.e. develop the UI in JS and leave only socket communication to Java.
Super. Let me check. Thanks for the tip.
Hi,
On 11/14/2010 09:22 PM, jtd wrote:
On Sunday 14 November 2010 17:56:52 Shamit Verma wrote:
What sort of client side state do you wish to maintain ? AFAIK, one is no longer bound to using Java for feature rich browser based applications. Javascript (in the macro sense that also includes jQuery, YUI, all of google's js stuff and the tons of ajax libraries that litter the web) is quite capable of turning the browser into a proper target platform for alternatives to most desktop based applications.
Javascript is not an optimal solution in this use case.
Based on initial email of this thread, aim it to control a robot from browser based UI. This requires very low-latency communication between UI and device.
True.
Yes and that's the reason I added in the initial response:
Where will the main 'engine' for the robot run ? on the robot's controller ? In any case, for this use case you needn't touch java at all IMHO. All client side stuff can be done using javascript.
Basically, if I were to go about doing this, I would separate the controller bit from the UI completely. Javascript is great for the UI bits. So again, how is the robot designed ? Where is the controller ? For example: is the controller one of the popular open hardware boards ? Basically, I was /highly/ recommend first designing the components and API that'll make up your system and then choosing the language. My personal recommendations:
- A python based controller (perhaps twisted[1] based) - A javascript based UI
If otoh, you want the controller itself running 'client' side completely (within the browser) you might want to muck around with NodeJS:
Disclaimer: I have no experience with using this myself, but people whose opinion I respect say good things about it.
hth, cheers, - steve
[1] http://twistedmatrix.com/trac/
Yes and that's the reason I added in the initial response:
Where will the main 'engine' for the robot run ? on the robot's
controller ? In
any case, for this use case you needn't touch java at all IMHO. All
client side
stuff can be done using javascript.
This was not about controller, that would in any case be independent of UI. Controller would be running on Robot and UI would be running inside a browser. UI needs to talk to this controller and JS is not the best option for that. JS restricts UI to http request/response based communication.
Communication within browser, is best handled in Java/Flex/Flash.
-Shamit
On 11/15/2010 11:05 PM, Shamit Verma wrote:
Yes and that's the reason I added in the initial response:
Where will the main 'engine' for the robot run ? on the robot's
controller ? In
any case, for this use case you needn't touch java at all IMHO. All
client side
stuff can be done using javascript.
This was not about controller, that would in any case be independent of UI. Controller would be running on Robot and UI would be running inside a browser. UI needs to talk to this controller and JS is not the best option for that. JS restricts UI to http request/response based communication.
Over-simplification much ?
http://en.wikipedia.org/wiki/Comet_%28programming%29 http://en.wikipedia.org/wiki/Reverse_Ajax
Umm, jtd's original post (and his replies) does not specify a controller independent of the UI. In fact, separating the two is also something that I suggested in my reply. In any case, blanket statements such as 'JS restricts UI to http request/response based communication' are not really useful.
Did you see the NodeJS link I sent in the previous mail ? The index page itself has an example of running a TCP server using nodejs.
Communication within browser, is best handled in Java/Flex/Flash.
I'm not a huge JS fan myself, but I'm even less inclined to use client side Java applets to do UI stuff.
btw, we've come a long way since the '90s
cheers, - steve
On Tuesday 16 November 2010 13:08:50 steve wrote:
On 11/15/2010 11:05 PM, Shamit Verma wrote:
Yes and that's the reason I added in the initial response:
Where will the main 'engine' for the robot run ? on the robot's
controller ? In
any case, for this use case you needn't touch java at all IMHO. All
client side
stuff can be done using javascript.
This was not about controller, that would in any case be independent of UI. Controller would be running on Robot and UI would be running inside a browser. UI needs to talk to this controller and JS is not the best option for that. JS restricts UI to http request/response based communication.
Over-simplification much ?
The whole problem is wanting on the fly changes anywhere in the chain, the whole system being highily experimental. It is likely to be more than 2 years in getting a fair idea of the actual field requirements. If i use a c/py/whatever core on the robot and a suitable standalone UI I would be maintaing a lot more code than a browser based setup. Besides there is the everpresent problem of bitrot in standalone isolated systems like this.
Further a browser based setup might help in simply plugging in additional frameworks (like VR) without too much problems.
From whatever I have read (and my highily biased everything-under-my-control view), it seems a lot of expermentation is on the cards.
-
jtd -
Nagarjuna G -
Shamit Verma -
Shirish Padalkar -
steve