Show Posts
5206
Pluto Main General Issues / Pluto 2 vs Previous Pluto ?
« on: December 05, 2004, 03:28:42 pm »
Hi Rob,
>> Can DCE be used for information retrieval...
The underlying class behind DCE itself is "Message", which is nothing but a message, or essentially a packet. It can be anything you want--binary data like a video, a packet of data in a stream, etc. Within your code you can create a DCE message of any type, with any ID, and attach anything to it. Just give it a destination device, group of devices, category of device, etc., and then pass it to SendMessage or QueueMessage. It will get to it's destination. Of course, the destination needs to know what to do with it and will ignore it if there's no handler for it. So you can really use it for anything at all.
>> Sphinx 4
That's great news. I wasn't one of the developers in our speech recognition efforts, but I know it was in the spring of 2003. It sounds like things have improved in the last 18 months.
>> Porting to the SE800 / SE900
There's actually almost nothing to do. All the code, the logic, the framework, etc. is in common base classes that is ansi C++. We had to write our own set of macros and classes to get Symbian to compile ansi C++. Natively Symbian C++ is quite different--instead of the stl list, they have their own mechanism. Their strings are completely different. So we had to write macros to do translation, and in some cases, like strings, write our own Symbian classes that mimiced the classes in ansi c++. But, with that work having been done, our ansi C++ code now compiles just fine in Symbian. The base classes then call methods: DrawImage, DrawRectangle, DrawText which is what the UI-specific class must implement. So, literally, 99% of the code is shared between Linux, Windows, CE and Symbian, and there are only a few functions specific to Symbian. And those functions are probably very similar, if not identical, between the Symbian flavors. Plus, in the case of our mobile phone app, all the graphics processing, text rendering, etc. is done on the PC side, which feeds pre-rendered bitmaps to display on the phone. We did this so we can run the same software on Java phones, and other proprietary platforms, like Motorolla's. It's probably no more than 50-100 lines of code that will change for each platform, and only a day or two of work.
>> Pluto license
You can distribute the software royalty free, but if you work for a manufacturer and want to embed the software into some existing hardware sold as a pre-installed combination, you do need a separate license. In our case, we took a huge risk going open source with our product since we work in a very competitive segment. We have a couple dozen programmers, as do our competitors, like Crestron, AMX, Core Access, Kaleidascape, etc. If there was no restrictions at all, our competitors could just drop their own engineering efforts and just use all our software to compete against us. So, the purpose of the Pluto license was to allow the same freedoms and rights as GPL for the open source community, which only cares about the software anyway since they're not manufacturing any hard good, but prevent our competitors from using our software on their hardware and selling it as their own product. Also, the Pluto License doesn't prohibit distribution with hard goods, it only requires a separate license, which may or may not even require a fee. It depends on what company wants to distribute it and as part of what product. We want everyone to be able to use our software for free, we just don't want our competitors to drive us out of business with our own product.
>> Video feeds
Are handled 2 ways: push or pull. You can add 'video' object to any screen within Designer, and just specify the source. It can be any device that knows how to provide video frames--a camera, Xine, etc. In that case it's a 'pull' system because when the orbiter gets to the screen it asks the other device for the video. Presently, the only message we implement is the 'Video Frame' message, and the orbiter requests this about twice per second (ie 2 frames per second). The other mechanism is a 'push', where another device sends the orbiter an 'update object image' command, telling the orbiter to put an image (or series of images) on the screen. More messages could be added to do a true streaming, either by embedding the video within the dce message, or sending a message telling the device to render video being broadcast over a udp port.
>> remote connection
When you leave the house, the Core sends the phone a 'message' by calling it using a regular phone call, but with an encoded caller ID. This requires going through a switch that is able to do this. The problem with other methods is they are not reliable. If you are on the phone, sms, mms and internet are cut off--it's a limitation of all the current cell phone providers. The only thing that gets through to you no matter what is another call. And you would be pissed off if you hung up the phone after a 45 minute call only to learn that your house was being robbed 30 minutes earlier but you missed it since you were on the phone. So, the software sits in the background 'listening' for incoming calls, and if the caller id matches a given pattern, it beeps and displays a message. For the phone to send requests back to the server, it just opens a web page basically, passing the outgoing data on the url, receiving the incoming data as the body of the page. This makes it very easy to add functionality (they're just web pages), and to implement security (you just need an SSL certificate so the web page is secure). In the future, for those who don't want their own ssl certificate, we will offer very cheap use of our SSL certificate so the phone can hit our servers, which will 'tunnel' through a secure ssh connection back to your server.
>> Video phone
Video phone is presently only supported on the Linux media directories. We use a heavily modified version of Linphone, and some extensions which allow us to route video over sip, so we can treat video calls just like normal phone calls (ie hold, transfer, voice mail, etc.). We're still a few weeks away from making this available with the series 2.
>> Auto login
Sorry... I'm not one of the php guys, but I know it actually was a real pain to get phpbb, mantis, mailman, and our own sites to use a unified login, so you wouldn't have to create separate user accounts for each. I think they're working on an auto-login for our site, which, since it's unified, will mean it will automatically login to the forums, bug tracking, etc. I don't know when that will be finished though.
Aaron
>> Can DCE be used for information retrieval...
The underlying class behind DCE itself is "Message", which is nothing but a message, or essentially a packet. It can be anything you want--binary data like a video, a packet of data in a stream, etc. Within your code you can create a DCE message of any type, with any ID, and attach anything to it. Just give it a destination device, group of devices, category of device, etc., and then pass it to SendMessage or QueueMessage. It will get to it's destination. Of course, the destination needs to know what to do with it and will ignore it if there's no handler for it. So you can really use it for anything at all.
>> Sphinx 4
That's great news. I wasn't one of the developers in our speech recognition efforts, but I know it was in the spring of 2003. It sounds like things have improved in the last 18 months.
>> Porting to the SE800 / SE900
There's actually almost nothing to do. All the code, the logic, the framework, etc. is in common base classes that is ansi C++. We had to write our own set of macros and classes to get Symbian to compile ansi C++. Natively Symbian C++ is quite different--instead of the stl list, they have their own mechanism. Their strings are completely different. So we had to write macros to do translation, and in some cases, like strings, write our own Symbian classes that mimiced the classes in ansi c++. But, with that work having been done, our ansi C++ code now compiles just fine in Symbian. The base classes then call methods: DrawImage, DrawRectangle, DrawText which is what the UI-specific class must implement. So, literally, 99% of the code is shared between Linux, Windows, CE and Symbian, and there are only a few functions specific to Symbian. And those functions are probably very similar, if not identical, between the Symbian flavors. Plus, in the case of our mobile phone app, all the graphics processing, text rendering, etc. is done on the PC side, which feeds pre-rendered bitmaps to display on the phone. We did this so we can run the same software on Java phones, and other proprietary platforms, like Motorolla's. It's probably no more than 50-100 lines of code that will change for each platform, and only a day or two of work.
>> Pluto license
You can distribute the software royalty free, but if you work for a manufacturer and want to embed the software into some existing hardware sold as a pre-installed combination, you do need a separate license. In our case, we took a huge risk going open source with our product since we work in a very competitive segment. We have a couple dozen programmers, as do our competitors, like Crestron, AMX, Core Access, Kaleidascape, etc. If there was no restrictions at all, our competitors could just drop their own engineering efforts and just use all our software to compete against us. So, the purpose of the Pluto license was to allow the same freedoms and rights as GPL for the open source community, which only cares about the software anyway since they're not manufacturing any hard good, but prevent our competitors from using our software on their hardware and selling it as their own product. Also, the Pluto License doesn't prohibit distribution with hard goods, it only requires a separate license, which may or may not even require a fee. It depends on what company wants to distribute it and as part of what product. We want everyone to be able to use our software for free, we just don't want our competitors to drive us out of business with our own product.
>> Video feeds
Are handled 2 ways: push or pull. You can add 'video' object to any screen within Designer, and just specify the source. It can be any device that knows how to provide video frames--a camera, Xine, etc. In that case it's a 'pull' system because when the orbiter gets to the screen it asks the other device for the video. Presently, the only message we implement is the 'Video Frame' message, and the orbiter requests this about twice per second (ie 2 frames per second). The other mechanism is a 'push', where another device sends the orbiter an 'update object image' command, telling the orbiter to put an image (or series of images) on the screen. More messages could be added to do a true streaming, either by embedding the video within the dce message, or sending a message telling the device to render video being broadcast over a udp port.
>> remote connection
When you leave the house, the Core sends the phone a 'message' by calling it using a regular phone call, but with an encoded caller ID. This requires going through a switch that is able to do this. The problem with other methods is they are not reliable. If you are on the phone, sms, mms and internet are cut off--it's a limitation of all the current cell phone providers. The only thing that gets through to you no matter what is another call. And you would be pissed off if you hung up the phone after a 45 minute call only to learn that your house was being robbed 30 minutes earlier but you missed it since you were on the phone. So, the software sits in the background 'listening' for incoming calls, and if the caller id matches a given pattern, it beeps and displays a message. For the phone to send requests back to the server, it just opens a web page basically, passing the outgoing data on the url, receiving the incoming data as the body of the page. This makes it very easy to add functionality (they're just web pages), and to implement security (you just need an SSL certificate so the web page is secure). In the future, for those who don't want their own ssl certificate, we will offer very cheap use of our SSL certificate so the phone can hit our servers, which will 'tunnel' through a secure ssh connection back to your server.
>> Video phone
Video phone is presently only supported on the Linux media directories. We use a heavily modified version of Linphone, and some extensions which allow us to route video over sip, so we can treat video calls just like normal phone calls (ie hold, transfer, voice mail, etc.). We're still a few weeks away from making this available with the series 2.
>> Auto login
Sorry... I'm not one of the php guys, but I know it actually was a real pain to get phpbb, mantis, mailman, and our own sites to use a unified login, so you wouldn't have to create separate user accounts for each. I think they're working on an auto-login for our site, which, since it's unified, will mean it will automatically login to the forums, bug tracking, etc. I don't know when that will be finished though.
Aaron