teknikill.net

[lou]

There has been talk of what I'd call intermediate protocols.
Protocols somewhere in between what the base speaks and one's actual program. I've been thinking of implementing one or more such protocol to make my code useful to more people.

The problem is one of guessing what you want.

There are several places where one might choose to implement such an interface. One is at the base level, where all commands are simply translated and forwarded. The other is at the handset level, where only commands addressed to/from that handset appear at the interface. A third option, which is very similar to the handset level, is the service level, where one of the parties to the communication is some sort of service handler.

The basic protocol itself, would probably be keyword/value based, terminated by a newline, with some sort of escaping scheme in case the data contains a newline, which, as far as I can tell, never happens in practice.

Even once all that is decided on, there is the matter of how the interface is accessed. Is it parent/child communication over stdin/stout? Does something listen on a network socket? If so, which party is doing the listening? Should it be some sort of broadcast medium? Shared memory? Multicast?

None if this is really for me; it is for you. If you don't want it, I won't bother. A document specifying the protocol will have to be compiled and agreed upon before I put a lot of work into implementation.

[Spektre]

Hmm,

I would like to be able to write vb.net applications with a minimum of hassle using the device.

I would like to be able to send information to the IMFree screen with formatting (character positioning) and graphics if the LCD is capable of displaying graphics.

I would like to either through an event or through polling get information from the keyboard.

Thus I suppose this is closest to the "service" level.

Spektre

[lou]

[Spektre]

Hmmm,

I will freely admit I have not defined OS hooks before in vb.net, simply use ones made before so I will most likely be slow on my end. Also, i am working on acquiring a few IM Free's currently.

There is a version of stdin/out in .net, but I don't see it routinely used.

There are probably other good ways to do it but a socket interface sounds good at first glance. Either straight tcp or maybe a telnet interface. That way, i could use premade events from the sockets class. Multicast might be another idea as you could have multiple listeners then.

Shared memory, probably not so great in Windows.

So...

Let's say my client either connects to a network socket or starts to listen for a multicast.

I am assuming the unit has one of its 9 lines of display reserved for the message you are currently inputting. Do the rest of the lines simply scroll up as used? Is there any information that cannot be removed from the screen (such as screen names to start the beginning of each line)? If not, then I would forsee a simple command structure ala...

Each line receiving is:

Each line sending is:

The daemon/service would add the address incoming to know which IMFree it is coming from and parse the address on the output string to know which it is going to.

Spektre

[lou]

[Spektre]

Yes, handling multiple handsets in the client would be easy enough, that way the daemon/service would simply pass all the information, and the client can filter which handset it is coming from/to.

I doubt I will be of much help in porting anything. I write fairly simple vb.net applications.

For the most part, all the applications I can think of use the IMFree as a "super remote control", and thus it would be more useful if logging in, leaving a chat, etc. are not exposed to the client. If they must be (i.e. it is too difficult to bury al of it in the daemon) simple defaults should be established to bypass this not often used functionality.

I'll try to check out the IMOpen CVS.

Spektre

[Spektre]

I don't see any files in the CVS.

edit: OK found it.

[Spektre]

Sorry, new to Unix cross-compiling. Is there a standard build of cygwin which includes a gcc compiler and everything else I need to get up and running? My use of this previously has been limited to needing the .dll for applications.

Spektre

[lou]

When you install cygwin using their install tool, you, at one point, are presented with a list of packages to install or not. It has been awhile since I've done it, but the ones you want are probably under a group called "Development" or similar. gcc, g++, libraries, binutils, make, etc. Doing the cygwin install that way will also install the DLL. I don't think cygwin is going to have some things you'll need, such as the boost libraries. Those, you'll just have to build yourself using the included directions. You should do that from within a cygwin command shell (as opposed to a DOS command box) so that the paths agree with what the build tools are going to want to see.

The install binary can be gotten from cygwin's web site. http://cygwin.com/ Look for the icon that looks like a black "C" with a green triangle in it. Those are links to the install tool.

If I had a windows machine, I'd be able to be of more help, but I do not.

[Spektre]

Well , I have some free time now that the holidays are over, but looking at this, I think it is out of the scope of what I do.

Cross compiling Linux aps for Windows doesn't seem so fun.

Good luck.

Spektre

[Spektre]

I guess this COULD end up being easy HAHA!

Lou are you still here. If you are willing to step by step me thru the cross compiling I'll give it a go. I have cygwin installed.

Spektre

[lou]