Announcement

Collapse
No announcement yet.

Requirements for a Web Front End

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Requirements for a Web Front End

    [Edit - this thread was created from several posts in this thread. I moved them here to keep the original thread clean.
    The topic is a conversation about the possibility of using user Sama's Velocity FE as the basis for a web based Front End. Velocity is open source and provides an architecture which separates the interface from the application. Currently, the interface is Flash based, but for iPad compatibility reasons, I was interested in an html5 based interface.

    This thread seems like a good place to document a discussion about what a web based front end would/should require. The earlier thread began with the question below by SapporoGuy - Bugbyte]


    @ bugbyte

    What is holding you back on going further with your mobile web OS?
    Or did I miss something?

  • #2
    Originally posted by SapporoGuy View Post
    @ bugbyte

    What is holding you back on going further with your mobile web OS?
    Or did I miss something?
    @Sapporo Guy - time and web knowledge.

    Time - I've purchased an igepv2 embedded Linux board. I'm having a real devil of a time getting Ubuntu on it because I'm Linux-stupid. I'll figure it out some day but not today.

    After that, I thought that Sama's Velocity FE would be a good core to put web page skins on. At first, I want to simply get it to run on the igepv2 in the car and serve the pages up to the iPad that way. Later, it can move off the car and onto the net if I want.

    I don't really know how all these bits and pieces tie together, so it's going to be a long uphill climb to ever get it working. I just thought that either Velocity or this project are headed in the right direction for a connected car install.
    Originally posted by ghettocruzer
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

    Comment


    • #3
      To some extent I can help.
      I don't do java ... Which is why I'm a bit hesitant to deal with velocity.
      Java as a bqcknd mechanism is great but you have to have people who know what they are or you'll be in the same place as flash. Slow!

      I wonder about the use of php in situation, it's great as a asp replacement for the top GUI layer but as a lower hardware level interaction I wonder if java, perl, python or ruby woldnt be a smarter choice.

      What are you looking for in a webFe?

      Comment


      • #4
        I'm experimenting with low power ARM based devices like the Sheeva plug and the igepv2 (similar to a Beagle Board). What I want to do is use Velocity's core and run it on the ARM device. The ARM device will run a web server and I'd like to be able to serve up the look and feel from coded web pages.

        Ultimately, those web pages would be accessible not just from the ARM device but from a web server on the net - perhaps using OSDash as a service to update the pages stored on the server or to find/store additional skins for the web page.

        It seems to me that with html5, it ought to be possible to build pages that don't have to look like web pages but act more like a web app. The speed may be an issue, but I think with a WiFi hotspot in the car, loading the pages won't take that long.

        I haven't looked at all of the functionality that Velocity provides yet. Right now, it seems like the appropriate architecture for this idea. The app itself runs in java. If it is on a Linux based device, scripts can be written to interface with dbus apps that tripzero and Nextabyte Matt are working on like bluemonkey for voltage monitoring, nobdy and obdgpslogger for obdii interface and also for control of the linux library and the fusion brain, for starters.

        What I don't know about are the proper technologies to do this stuff.

        I'm having a devil of a time learning enough to get Ubuntu on my igep but one day I will figure it out. Then, I want to load apache server on it and see if I can get Sama's Velocity backend running as-is.
        Originally posted by ghettocruzer
        I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
        Want to:
        -Find out about the new iBug iPad install?
        -Find out about carPC's in just 5 minutes? View the Car PC 101 video

        Comment


        • #5
          Why would we use Velocity FE as the basis for a web front end. What advantages would that give us?

          I was wondering, because i was hoping to code a custom frontend for my carputer once i get the hardware. Because i'm only fluent in PHP and some vb6, it would be web based.
          I've got OBD2 readings to display on webpages already, justneed to start work on a media section.

          - Dont mean to hijack the thread.... back on topic now. lol

          Comment


          • #6
            There are several Ajax kits to look at mocha, jquery and yahooUI of course there are more. Jquery will basically allow you to do most of the ui in a app like fashion. So this is just an exercise of putting on the right pieces to create that iPhone feel.

            There's even eyeOS that can make your browser feel like a desktop.

            But, this is not really about UI but more of a backend middle layer issue. Meaning that I have doubts that a server is really where things are headed. Data yes, main program????hmmm ....

            Hardware I'm going to agree. A small unit with low level power drain is going to be awesome. But you still need a gpu to provide the final monitor experience.

            Comment


            • #7
              I may have pointed this out before... or may not have... but there is a better solution than flash and its Qt WRT which is akin to Adobe Air except that it exposes more system level services and supports html5. Basically gives you system level access to services via the W3C "widgets" APIs for location, sensors and more through javascript objects.

              I've played around with it a bit and found it to be very fast. I was able to render javascript "evals" faster than I was in Google Chrome (which iirc holds the speed record for browsers). It also supports flash just like a browser would.

              I think WRT sports a plugin based system where you can create additional services to expose things like OBD-II etc to javascript objects.

              Find out more here:
              http://labs.trolltech.com/blogs/2010...ourney-begins/

              It's a young project, but it has a lot of potential. Just thought you might appreciate the knowledge even though it sounds like you are pretty sold on flash.
              Former author of LinuxICE, nghost, nobdy.
              Current author of Automotive Message Broker (AMB).
              Works on Tizen IVI. Does not represent anyone or anything but himself.

              Comment


              • #8
                what system level api's does one need?
                Or just the ability to run a bash script?

                Comment


                • #9
                  Cool stuff but a bit down the road and probably a major need to write drivers for a large share of hardware .... Bummer

                  I don't think bug is really into flash but rather looking for a backend to support his server based idea. I am not a flash fan. Cool but just too many apps on flash that aren't programmed to watch memory properly.

                  I really can't put my finger on this but I'm having trouble thinking that apache/mongrel/lighthttpd (errr, name is wrong) being a center for my in-car.

                  Moreover, will a server based system be robust enough to support the coming generation of expected net+iOS features that users think they will need?

                  However, I do buy into the idea that in-car needs to be on-line to access the growing amount of content that is going to coming down the pipes in the future.


                  Vision: in easy terms -- iOS for the car
                  a system that goes beyond your regular OS but yet having the power of an OS. Something along the lines of meego but developed as far as CF/OM/RR but yet this in-car is the OS And app at the same time

                  Comment


                  • #10
                    Well, here's *my* requirements, based on the setup in my car which is igepv2 ARM Linux device with server, WiFi access point, and iPad as control device.

                    Requirement 1:
                    The iPad is connected to the audio, thus one requirement I would have is to play the music in the browser.

                    Requirement 2:
                    No Flash. For obvious reasons, I'm not interested in Flash but rather html5.

                    API's/Interfaces:
                    I've played around a bit with php and there is a dbus connection there. Much of the software that tripzero has been writing for Linux communicates using dbus. For other issues, the ability to run a script would probably be nice.

                    The things off the top of my head would be OBDII information, GPS information and Fusion Brain control capabilities.

                    Use of Velocity:
                    The only reason I bring up Velocity is that Sama has already done some of the work and it is open source. I've had a couple of back and forth conversations with Sama and the model he used to develop separates the user interface from the backend. The Flash is only on the UI side and an alternate UI could be coded that calls the same routines if necessary. Seems unnecessary to reinvent IF some of the groundwork has already been done.

                    [Edit: I'm on the client-server side of things because my vision for the future is of a core FE that takes care of a lot of familiar stuff, augmented by apps or programs that provide functionality that is outside the core or makes the program monolithic. Example: an FE that controls hvac, does many forms of music -mp3, streaming audio, internet radio, but does not do, say, GPS. That comes from a separate app that you run concurrently and switch to as necessary.

                    This allows users to add functionality without having to update the FE app. Serving the FE to the client allows a core program to function with a phone, an iPad, a PC, or whatever else you may have that can connect. Each would have it's own screen without having to have its own app. Screens could change based on location or device and new screens would be as easy as selecting a different interface site or file name.]
                    Originally posted by ghettocruzer
                    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
                    Want to:
                    -Find out about the new iBug iPad install?
                    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

                    Comment


                    • #11
                      Updates: from a central web server will require bandwidth I turn will require a revenue stream. Where as a simple script update will be less hungry.

                      I think a major focus area will be information serving versus page serving. This will allow a future that will allow tapping of possible revenue.

                      Code:
                      Ruby on Rails and Django (python) might be better languages to use since they allow rapid development, MVC, and lower level system scripting. Cakephp is close but performance and versatility is an issue. However, optiflex is php person ao that might also influence which language to choose. I am a php person, but looking to future is more important that what I'm used to.

                      Mashup:
                      how about a combination of Ice+OM+web factoring?
                      I'm thinking that a meego like enviornment combined with web services and OS built-in application really would allow a larger user base to be built.

                      I say this because windows + FE is really a task that needs serious time investment that most people just don't want to deal with.

                      Is the new appleTV up to this task?

                      Comment


                      • #12
                        Not sure I'm following you - with the AP in the car, although I may use a lot of bandwidth, it is free over WiFi.

                        I do agree about the information serving vs. page serving. Does that mean you are talking about some type of local server running on the car pc computer that stores pages retrieved from a central server and provides the UI that passes information to lower level code that can interact with the computer's hardware?

                        That is certainly the model I had in mind. Rather than a 'Front End' in the traditional monolithic sense, I'm thinking of the web pages as being a front end to lower level code/apps on the back end.

                        --------------------------------------
                        For example, tripzero has written several pieces of software on Linux. Nodby interacts with the car's OBDII connection. Bluemonkey monitors the voltage of a dc-dc power supply over USB, and Proximity monitors bluetooth and WiFi and takes certain actions when it detects your phone or home WiFi.

                        A web front end would be able to interact with this software by providing configuration pages or displaying information from these applications. Since they use dbus, it *seems* to be a matter of coding pages and a certain amount of middleware to interact with them.

                        A package of apps for typical tasks could comprise clients for the web front end, accompanied by some sort of middleware -perhaps in java, that would run on the server in the car. Ideally, these apps would be open source, to prevent being too reliant on a particular application.
                        Originally posted by ghettocruzer
                        I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
                        Want to:
                        -Find out about the new iBug iPad install?
                        -Find out about carPC's in just 5 minutes? View the Car PC 101 video

                        Comment


                        • #13
                          Hey all

                          Nice to see all the interest around a web based FE. I've always had this vision for cars.

                          Some Background
                          The idea behind Velocity was to approach carpc's from a distributed point of view, such that multiple devices could hook into the car's central server and use its services, then present them in whatever way they needed to. Be it aural, visual, whatever.

                          From an abstract point of view the requirement is: An SOA framework (Service Oriented Architecture) that allows developers to write services (audio/video service, OBD service, file system service, etc). These services can be accessed by clients using messages transmitted through a protocol on some transport. The clients can deal with the presentation of the information to the interaction with the user.

                          From an implementation point of view, the key words from the above are:
                          SOA framework, services, client, messages, protocol, transport, presentation and interaction.

                          Velocity (SOA framework) used Java (services) and a touch-enabled (interaction) web browser (client) with Flash (presentation) that talked using JSON (messages) over TCP (protocol) on Ethernet (transport).


                          The New Requirements
                          If you'd like to change that to be:

                          Velocity (SOA framework) uses Java (services) and a touch-enabled (interaction) web browser (client) with HTML5/JS (presentation) that talks using JSON (messages) over TCP (protocol) on Wifi (transport).

                          Then that's fairly easy as swapping Flash for HTML5/JS can speak JSON all the same, and Ethernet swapped with Wifi should be seamless (bandwidth permitting).


                          Improvements

                          If I was to rewrite Velocity today, I would do the following:

                          Messaging
                          Back then, I built an ActionScript/Java bridge that spoke JSON and used reflection around Java objects to do a lot of translation magic. Today, a new framework exists called DWR which does what I tried to do and 100 times better as it allowes reverse ajax and all sorts.

                          Language
                          Java is getting old and there's a new kid on the block called Groovy. This is built in Java but is a dynamic language.

                          Grails is a web framework built on Groovy (Groovy on rails = grails). Grails has a great plugin-architecture that allows you to do: grails install-plugin dwr - and you suddenly have DWR support in your codebase. Magic!

                          I've written a few Grails apps with DWR and it makes what I was trying to do with Velocity much much easier. Say you want access to the filesystem. You just expose the standard java file api to DWR and you can have access to all these functions from javascript. This gives you the power of having OS-level functions at the front end!

                          Obviously you wouldn't use this power to write services, but you would use it to access services. So say you get an OBD interface in there. You write a Groovy service for it that takes care of the driver and messages to it, and gives you calls like "getThisInfo" and "writeThatMessage" to the OBD device, and you'll a web based client that is doing things with your car. Then assuming you have semantically correct HTML, you'll be able to do magic with CSS (especially with CSS3 around the corner).

                          Since Grails is still Java based, it should work out of the box on any platform.


                          Verdict
                          You can use Velocity as an experiment to get what you want going. If you want Velocity to be a long term solution, I would suggest the improvements above are made and this will provide a solution with very long legs.


                          Why don't I do it?
                          I'd love to do this as I have a passion for all things cars and car pc based. However, I currently have a job leading a team of 22 java developers that are redefining the way the BBC produce television so I'm fairly busy with my job.

                          Then I have another project I'm doing with my brothers in all my spare time that I'm hoping will make us some money. So my time is so tight, I'm surprised I even had time to type all this out! But I do love the carpc community and would love to give something like this.

                          I'm happy providing free consultancy to someone that's interested in taking the project on.
                          Current:
                          [BMW E46 ///M3 Convertible]

                          Previous:
                          [BMW E31 850CSi]|[BMW E39 535i]|[BMW HVAC Research]|[IBUS Scrolling Text]|[BMPuter]|[Velocity]|[TomTom]|[Vision]|[Space Navigator Driver]|[Super Fast Boot]

                          Comment


                          • #14
                            Improvements (continued)
                            For video, Velocity superimposed a frameless mplayer window on top of a flash. I did this for performance reasons on low-end machines. This should however be changed so mplayer/ffmpeg is used to transcode videos on the fly to h.264 video and transmitted over the wire.
                            Current:
                            [BMW E46 ///M3 Convertible]

                            Previous:
                            [BMW E31 850CSi]|[BMW E39 535i]|[BMW HVAC Research]|[IBUS Scrolling Text]|[BMPuter]|[Velocity]|[TomTom]|[Vision]|[Space Navigator Driver]|[Super Fast Boot]

                            Comment


                            • #15
                              one more thin bugbyte, have you considered using a DLNA server with a client on the iPad?

                              That may be your quickest route to market for the time being whilst you get the rest of this up and running
                              Current:
                              [BMW E46 ///M3 Convertible]

                              Previous:
                              [BMW E31 850CSi]|[BMW E39 535i]|[BMW HVAC Research]|[IBUS Scrolling Text]|[BMPuter]|[Velocity]|[TomTom]|[Vision]|[Space Navigator Driver]|[Super Fast Boot]

                              Comment

                              Working...
                              X