Related
Hi Folks
What I'm after, and I'll pay if necessary, is a bit of database software for my PPC.
I'm hoping to create a database that would have a variety of information plus at least one image attached, possible more.
This database would consist of technical information and the image would be a pictoral representation of this (such as a picture showing the size of a machine in respect to its capabilities).
As an addition I'd like to be able to list the facts of each of these records in tabular format.
Once I've got a PPC piece of software I can then write up the database in it's PC equvilent.
On the PC I'd probably use MS Access as I have that installed.
Is this too complicated or would you like more information?
TIA
Elwyn
What about the WindowsCE version of SQLServer?
Edit: http://www.microsoft.com/sql/editions/sqlmobile/default.mspx
Thanks, installing it now Will let you know how it goes...
i work with alot of really big databases (24 million rows in the biggest) in my day job, tired a few PPC versions theres nothing decent that will work with 65k+ rows.
if you do a google on it there is articles and posts on various forums that talk about it.
only thing ill carry on the ppc is summarys of the stuff in the databases incase i need it in meetings and what not.
St3v3
Thanks for your information. The database would not have more than, ooh, at most, erm, 500 records.
Each record would probably be at most 20 fields per record with at least 1 image with possible more. I am glad in a way that I do not deal with such large databases though My job involves me being outdoors and outside and away from computers
I already STFA and did not find what I was looking for. I was wondering if there is an application that will allow viewing of existing Google Sketchup files, editing/creating files - no - not so much, think that would be best done on a full blown desktop, One earlier post was asking about running a fully functional Sketchup, and I tend to agree that it would be too much of a tax on the processor and memory to be feasible for a mobile device. I also found the SketchBook program from AutoDesk which is designed for mobile devices but from what it says it is more like Paint in Microsoft Os's not a CAD type program.
Anybody know if there is anything like that available out there to be able to view Google Sketchup files? Thanks in advance for any information on the subject.
Sorry to wake up an old topic (very old) but I too am looking for such an app.....being a kitchen builder in my spare time I was asked a few times if I had any models on hand to show. And since I do all my sketches in Sketchup, well you guessed it....I can't show them on my tab....
Would be kinda cool to show potential customers how their kitchen might look like if I could just drop existing cabinets in place etc...
If you've already found something would you mind sharing with me? Very much appreciated...
The data can be sent as a simple byte stream.
I want to capture a PC screen and send it to WP7, I must convert it in server side and reconvert it in client side (I don't know how do that).
The code that I developed to capture the PC screen give me a bmp image extension, and the WP7 can't read that file.
How do I serialize media objects (pictures) for socket transfer??
I want to be able to send pictures files from Pc to WP7 via WiFi using socket.
How can I convert the picture file to what the file extension stream and send it?
I am confused how to do that
juste_3al_faza said:
The data can be sent as a simple byte stream.
I want to capture a PC screen and send it to WP7, I must convert it in server side and reconvert it in client side (I don't know how do that).
The code that I developed to capture the PC screen give me a bmp image extension, and the WP7 can't read that file.
How do I serialize media objects (pictures) for socket transfer??
I want to be able to send pictures files from Pc to WP7 via WiFi using socket.
How can I convert the picture file to what the file extension stream and send it?
I am confused how to do that
Click to expand...
Click to collapse
I think I need to know a little more about what you are trying to do.
I am assuming a program is running on the PC. You want to capture an image of the program. Then send it to the phone through WiFi.
For it to be readable on the phone, bmp will not work. Convert it to jpg. Plenty of free algorithms and libraries can be can be found to do this.
To transfer it to the phone, I would suggest using a webserver or hosting one on the same machine. Possibly Apache, since it is free, but i am more familier with IIS.
Have your app on the pc do a post to page on localhost. Have it pass something on the querystring to identify the phone it is for. This page will store the image in a location on your computer that the webserver has access to.
Now your phone will need an app that will also hit that same ip address, not local host. You will need to know the ip address of the machine. Have it hit a different page and pass that phone identifier. The page will do a redirect to the jpg file. As you recieve the output, write it to to a file on the phone. Using Redirect should automatically send the name and mimetype with the response.
There are other more complicated ways to stream an image, but this is the simplest.
You could always have the webserver be on a different machine entirely, which would make it more generic. Yiou could even have it be hosted so it is accessible from the internet, not just the intranet.
Usign a webserver seems vastly over-complicated to me, but OK. Maybe I'm just more comfortable writing netwrok code than most people...
Take your screenshot (I assume you already managed this). Put it in a format the phone likes (JPEG is good; there might even be BMP-to-JPEG conversion code in the .NET library). Connect the phone and the PC.
This is where the network code comes in. I would personally do this by starting a TCP server socket on the PC on some arbitrary high port, more than 1024 and less than 65000. Have it "Listen()" for a request from the phone. Write a phone app that opens a TCP connection to the PC on that port. Once the phone connects, set it waiting to Receive() data. On the PC side, since some signal that you're going to transfer a file (a realllllly simple protocol would be to just send the file size, as an int, first). There are a few ways to send data on a TCP socket; you can use the Send() function which takes an array (type byte[], which could be populated by using another array and then converting), or a NetworkStream, which is just like any other member of System.IO.Stream (I'm assuming you're writing both ends in .NET, although really simple netcode is actually easier in C). To transfer the file itself, just open it and read it however you like, and send the byte array over the socket. On the phone end, create a new IsolatedStorage file, and write the data coming over the socket into it. Just read in a loop until you've read up to the size that the server told you was coming, or until you hit the end of the stream / the connection closes (which indicates a bug or a problem on the other end).
That's a dead-simple and not very robust network protocol, but it does have the advantage of being trivial to code up...
Or, if that all sounds too confusing, you can try using HTTP. I actually find that to be *more* painful, but YMMV; I cut my first netcode in C and to me HTTP feels needlessly complex by comparison (because it's meant to do so many more things than just transfer a simple byte stream like a file). If you want to look at the source code of an app that uses HTTP to send and receive files, including both the phone app and the PC server app, take a look at WP7 Advanced Explorer (it's on Codeplex). Ignore the parts about filesystem and registry for now, and just look at the network part.
To me the web server approach may seem to be the easiest solution because I have been doing dot net web programming since before dot net 1.1 came out (beta 1.0). Before that I was doing other web development using classic asp, xml, xsl, and javascript. So, I have been working with IIS for well over a decade.
Quite recently, I just worked on dot net code to stream documents and video that is not directly accessible through any virtual directory, without doing a redirect for the purpose of enforcing additional security.
Different types of programmers find different things easier. I have done little to no direct sockets programming since college, so that to me would be more difficult, even if it is actually easier.
It didn't even occur to me to try listening on a port.
Also, now that you mention it, there are ways built into dot net to convert image types. I actually use them in some of the programs I've written for Windows Mobile, such as the FB pic to Outlook Pic application. I might be converting the other way in that app though.
I don't think I do that with web service
I prefer to use the Socket.
My apps let me just view the PC screen
juste_3al_faza said:
The data can be sent as a simple byte stream.
I want to capture a PC screen and send it to WP7, I must convert it in server side and reconvert it in client side (I don't know how do that).
The code that I developed to capture the PC screen give me a bmp image extension, and the WP7 can't read that file.
How do I serialize media objects (pictures) for socket transfer??
I want to be able to send pictures files from Pc to WP7 via WiFi using socket.
How can I convert the picture file to what the file extension stream and send it?
I am confused how to do that
Click to expand...
Click to collapse
With the zune.
In order to develop an app remote desktop WP7, I started to with a desktop simple viewer and it works
but the problem that not show all actions that I do in Server side, that's video in YouTube can show you my problem
"watch?v=3q-FumfYsPQ&feature=youtu.be" (add it after /)
I use socket connection and I decode and encode my data (images).
this my code in WP7 client side
void Conncet(string IP_Address) {
client_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
SocketAsyncEventArgs socketEventArg = new SocketAsyncEventArgs()
{
RemoteEndPoint = new IPEndPoint(IPAddress.Parse(IP_Address), 4532)
};
socketEventArg.Completed += OnConncetCompleted;
client_socket.ConnectAsync(socketEventArg);
}
void StartReceiving()
{
byte[] response = new byte[131072];
SocketAsyncEventArgs socketEventArg = new SocketAsyncEventArgs();
socketEventArg.Completed += OnReceiveCompleted;
socketEventArg.SetBuffer(response, 0, response.Length);
client_socket.ReceiveAsync(socketEventArg);
}
private void ViewReceivedImage(byte[] buffer)
{ try { MemoryStream ms = new MemoryStream(buffer);
BitmapImage bi = new BitmapImage();
bi.SetSource(ms); MyImage.Source = bi;
ms.Close();
}
catch (Exception) { }
finally { StartReceiving();
} }
this my code in Server side (PC) sending images
void StartSending() { while (!stop)
try
{
Image oldimage = scr.Get_Resized_Image(wToCompare, hToCompare, scr.GetDesktopBitmapBytes());
//Thread.Sleep(1);
Image newimage = scr.Get_Resized_Image(wToCompare, hToCompare, scr.GetDesktopBitmapBytes());
byte[] buffer = scr.GetDesktop_ResizedBytes(wToSend, hToSend);
float difference = scr.difference(newimage, oldimage);
if (difference >= 1)
{
SenderSocket.Send(buffer);
}
}
catch (Exception) { }
}
My question is how can I make the send and receive fast to show the PC screen in WP7 in +/- real time.
The short answer is, you can't. Even if you compress the screen images first, which I note you're not doing, the amount of data is just too great. An uncompressed 800x480x32-bit image (such as WP7's screen can display) is 1.5MB. That's each frame. You can halve that by using 16-bit color, of course; now it's .75MB per frame. If you want even 20 frames per second - which is slower than TV or almost any video camera, but is moderately smooth for most things - that's 15 MB/sec, which is 120Mbps (about twice the speed of most WiFi, faster even than most wired networks).
With some simple image compression combined with clever data differencing (sending only the parts of the image that change), you could probably reduce that data load by at least a factor of 10. That's still too high for most Internet connections (even if your phone can download 12 Mbps, your PC probably can't upload it) but it might be usable over WiFi (802.11n probably, 802.11a or g maybe). You'd have to make your code quite a bit more complicated, of course. Additionally, the phone's processor would have to work a lot harder, since it would be decompressing the data and applying it to the changed part of the frame, instead of just dumping netowrk packets into an image buffer.
The real solution, of course, is to use one of the several programs and protocols that already exist and have the intended purpose of doing exactly what you're trying to do. The most common on Windows is called Terminal Services or Remote Desktop (Remote Desktop Protocol). Nearly all versions of Windows come with the client, and the better editions come with the server. On WP7, there are already some client apps available; the one I use is called "RemoteDesktop" (no space). Note that, in addition to having a well-optimized algorithm for screen updates (but it's *still* not going to be smooth for things like movies or games), Remote Desktop Protocol lets you control the PC directly as well.
Thanks
I look that's apps in marketplace and it looks very difficult to me, but I develop simple viewer and next time I will develop the code that can remote the PC.
the idea about send only that pixels that changed between the old image and the new image is really good, but how I ca send only that pixel and they're position in the image, that's a question.
And about compression, how I can do that with images?
Well, just compressing the full screen to .PNG or .JPG and sending it would shrink things considerably. There are .NET libraries available (there might even be one in the core library) for image compression. Alternatively, there are some excellent C/C++ libraries available, if you can code native interop. I know the phone has built-in capability to handle JPG, not sure about PNG though.
However, once the data is compressed it's hard to extract a part of it and send just that part. What I suggest you do instead is identify the portion of the image that changed. For example, if all the changed pixels fall within one rectangle, use that. Send the coordinates of the rectangle (its origin and either the opposite corner or the length/width), followed by the updated data. On the phone, listen for the rectangle to update, then write the updated data into those coordinates on the display.
Note that you may want to send multiple rectangles - for example, if the top left nd bottom right pixels change, but nothing else does, a single rectangle that encompasses both of them would have to be the entire image. Instead, send two tiny rectangles - one for each corner - and you can massively reduce the data needed. However, the process of quickly detecting a good way to break up an image into the parts that are and are not moving is tricky. You're essentially trying to create a video compression algorithm here, and although I know a little of the theory, it's totally not my area and I don't know much more than what I've told you so far.
Thanks again
I found something similare to know the pixel that chaged
Image Comparison using C#
http://www.c-sharpcorner.com/uploadfile/prathore/image-comparison-using-C-Sharp/
I will try to study it and get information how to set the coordinates, but the problem that stay is how I send it to the right position in image in client side
juste_3al_faza said:
I look that's apps in marketplace and it looks very difficult to me
Click to expand...
Click to collapse
I don't understand that. What is "difficult"? Enable RDP access on desktop? Or add your desktop ip address to the WP7 app? Take a look to the RemoteDesktop app by Topperware: it's fast, professionally designed and easy to use but of course not a free (however $4.99 is not much!)
As for me, it looks like you are trying to "invent a bicycle" but without basic knowledge how the remote access protocols should work. It's not that easy like just a transfer bitmap images via sockets...
I mind I don't need to use it, I want to develop a simple apps because its my project and I will get a note and pass my last year in school
juste_3al_faza said:
I mind I don't need to use it, I want to develop a simple apps because its my project and I will get a note and pass my last year in school
Click to expand...
Click to collapse
Now I understand OK, I can recommend you to dig in MJPEG. There are few Silverlight classes available on the web (you may google em); they may simplify your job. The picture quality isn't good or sharp enough but should be good for the student project.
you talk about compression images to mpeg????????????
have you an idea when I zoom In image in WP7, most image be clear to see, how I can do it?
Edit (After see the article about MJPEG silverlight)
It use the HTTP connexion and I use socket, It can work together?
If yes how I can combine with it (plz a sample code can help )
No, I'm talking about M(otion)JPEG over HTTP, easiest possible video streaming implementation. For the solution, you need to implement your own M-JPEG HTTP server application, and on WP7 you may use (it's already exists, google for MJPEG MediaStreamSource) MediaElement. And I don't understand your second question.
I already edit my previous post
and about the 2nd question, I mean when to pinch in WP7 screen, is the image will be clear or not.
I don't have time to write an example for you; however it's your project or homework , I just give you a direction.
As for seconds question (as far as I understand): it's depends from the image dimensions and JPEG compression level. If you resize 1920x1080 image to 800x480 with 50% quality, resulting image will looks not so good.
P.S. Check this project: http://mjpeg.codeplex.com/ To estimate output quality on Wp7, you may use any MJPEG desktop streaming solution (vlc, for example).
Thanks a lot
I finished my app and it work good, see the video
http://www.youtube.com/watch?v=cCwsuj7Hcno
Cool. Looks like you get about a frame per second, which won't work for showing a video but is fine for a Powerpoint or something, and a decent proof of concept.
I'm not sure I'd recommend demoing using a video showing a commercial movie with a clearly visible "Uploaded by..." comment, at least in the USA schools tend to frown on open displays of media piracy. Otherwise, well done.
Ok next time I will use PowerPoint to use my app show
I implemented a browser based encryption solution which runs on Windows RT (and many other Windows computers). All I wrote was the HTML page, I am leveraging Crypto.JS javascript library for encryption algorithm. I am using the HTML 5 File API implementation which Microsoft provides for reading and writing files.
I make no claim on this but seems to work good for me. Feel free to feedback if you have any suggestions. The crypto.js library supports many different algorithms and configuration so feel free to modify it to your own purposes.
You can download the zip file to your surface, extract it and load the TridentEncode.htm file into Internet Explorer.
If you want to save to custom directory you probably need to load it from the Desktop IE instead of metro IE (to get the file save dialog). I usually drag and drop the file onto desktop IE and from there I can make favorite. This should work in all IE 11 and probably IE 10 browsers... if you use other browsers you may need to copy paste into the fields since the File API implementation seems rather browser specific. Running the html page from the local filesystem means that there is no man-in-the-middle which helps eliminate some of the vulnerabilities of using a javascript crypto implementation. You could also copy the attached zip file to your skydrive to decrypt your files from other computers.
Skydrive files in theory are secure (unless they are shared to public) so this might be useful for adding another layer of protection to certain info.
Again, use at your own risk, but feel free to play around and test it, and offer any suggestions or critiques of its soundness, or just use it as a template for your own apps.
Ok... this is really cool! Nice idea, and a good first implementation.
With that said, I have a few comments (from a security perspective). As an aside, minimized JS is the devil and should be annihilated with extreme prejudice (where not actually being used in a bandwidth-sensitive context). Reviewing this thing took way too long...
1) Your random number generation is extremely weak. Math.random() in JS (or any other language I'm aware of, for that matter) is not suitable for use in cryptographic operations. I recommend reading http://stackoverflow.com/questions/4083204/secure-random-numbers-in-javascript for suggestions. The answer by user ZeroG (bottom one, with three votes, as of this writing) gets my recommendation. Unfortunately, the only really good options require IE11 (or a recent, non-IE browser) so RT8.0 users are SOL.
NOTE: For the particular case in question here (where the only place I can see that random numbers are needed is the salt for the key derivation), a weak PRNG is not a critical failing so long as the attacker does not know, before the attack, what time the function is called at. If they do know, they can pre-compute the likely keys and possibly succeed in a dictionary attack faster than if they were able to generate every key only after accessing the encrypted file.
2) Similarly, I really recommend not using a third-party crypto lib, if possible; window.crypto (or window.msCrypto, for IE11) will provide operations that are both faster and *much* better reviewed. In theory, using a JS library means anybody who wants to can review the code; in practice, the vast majority of people are unqualified to either write or review crypto implementations, and it's very easy for weaknesses to creep in through subtle errors.
3) The default key derivation function (as used for CryptoJS.AES.encrypt({string}, {string})) is a single iteration of MD5 with a 64-bit salt. This is very fast, but that is actually a downside here; an attacker can extremely quickly derive different keys to attempt a dictionary attack (a type of brute-force attack where commonly used passwords are attempted; in practice, people choose fairly predictable passwords so such attacks often succeed quickly). Dictionary attacks can be made vastly more difficult if the key derivation process is made more computationally expensive. While this may not matter so much for large files (where the time to perform the decryption will dominate the total time required for the attack), it could matter very much for small ones. The typical approach here is to use a function such as PBKDF2 (Password-Based Key Derivation Function) with a large number of iterations (in native code, values of 20000-50000 are not uncommon; tune this value to avoid an undesirably long delay) although other "slow" KDFs exist.
4) There's no mechanism in place to determine whether or not the file was tampered with. It is often possible to modify encrypted data, without knowing the exact contents, in such a way that the data decrypts "successfully" but to the wrong output. In some cases, an attacker can even control enough of the output to achieve some goal, such as compromising a program that parses the file. While the use of PKCS7 padding usually makes naïve tampering detectable (because the padding bytes will be incorrect), it is not a safe guarantee. For example, a message of 7 bytes (or 15 or 23 or 31 or any other multiple of 8 + 7) will have only 1 byte of padding; thus there is about a 0.4% (1 / 256) chance that even a random change to the ciphertext will produce a valid padding. To combat this, use an HMAC (Hash-based Message Authentication Code) and verify it before attempting decryption. Without knowing the key, the attacker will be unable to correct the HMAC after modifying the ciphertext. See http://en.wikipedia.org/wiki/HMAC
5) The same problem as 4, but from a different angle: there's no way to be sure that the correct key was entered. In the case of an incorrect key, the plaintext will almost certainly be wrong... but it is possible that the padding byte(s) will be correct anyhow. With a binary file, it may not be possible to distinguish a correct decryption from an incorrect one. The solution (an HMAC) is the same, as the odds of an HMAC collision (especially if a good hash function is used) are infinitesimal.
6) Passwords are relatively weak and often easily guessed. Keyfiles (binary keys generated from cryptographically strong random number generators and stored in a file - possibly on a flashdrive - rather than in your head) are more secure, assuming you can generate them. It is even possible to encrypt the keyfile itself with a password, which is a form of two-factor authentication: to decrypt the data that an attacker wants to get at, they need the keyfile (a thing you have) and its password (a thing you know). Adding support for loading and using keyfiles, and possibly generating them too, would be a good feature.
The solutions to 3-5 will break backward compatibility, and will also break compatibility with the default parameters for openssl's "enc" operation. This is not a bad thing; backward compatibility can be maintained by either keeping the old version around or adding a decrypt-version selector, and openssl's defaults for many things are bad (it is possible, and wise, to override the defaults with more secure options). For forward compatibility, some version metadata could be prepended to the ciphertext (or appended to the file name, perhaps as an additional extension) to allow you to make changes in the future, and allow the encryption software to select the correct algorithms and parameters for a given file automatically.
Wow thanks GDTD that's great feedback
Not sure about his minified sources, the unminified aes.js in components is smaller than the minified version (which I am using) in rollups. I'll have to look into what his process for 'rollup' is to see if I can derive a functional set of non-minified script includes. If I can do that it would be easier to replace (what I would guess is) his reliance on Math.random.
His source here mirrors the unminified files in components folder : https://code.google.com/p/crypto-js/source/browse/tags/3.1.2/src
msCrypto that would be great, I had no idea that was in there. I found a few (Microsoft) samples so I will have to test them out and see if I can completely substitute that for crypto.js. Would be more keeping in line with the name I came up with.
Currently this version only works for text files, I am using the FileAPI method reader.readAsText(). I have been trying to devise a solution for binary files utilizing reader.readAsArrayBuffer but as yet I haven't been able to convert or pass this to crypto.js. I will need to experiment more with base64 or other interim buffer formats (which Crypto.js or msCrypto can work with) until I can get a better understanding of it.
Metadata is a great idea, maybe i can accommodate that with a hex encoded interim format.
You seem extremely knowledgeable in the area of encryption, hopefully i can refine the approach to address some of the issues you raised by setting up proper key, salt, and IV configuration... I'm sure I will understand more of your post as i progress (and after reading it about 20 times more as a reference).
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?
nazoraios said:
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?
Click to expand...
Click to collapse
I cant comment too much on the encryption, GoodDayToDie has covered anything I could contribute and more. But there is a functioning web server on RT. Apache 2.0 was ported: http://forum.xda-developers.com/showthread.php?t=2408106 I dont know if everything is working on it, I dont own an RT device and last time I tried I couldnt get apache to run on 64 bit windows 8 anyway (needed it at uni, spent hours going through troubleshooting guides and it never worked on my laptop, gave up and ran it under linux in virtualbox where it took 2 minutes to have functioning the way I needed it to).
Curious about the performance. Speaking of encryption, 7-Zip has it built-in, and from the discuss in StackExchange, it seems pretty good.
One of the neat things about this thing (local web app? Pseudo-HTA (HTml Application)? Not sure if there's a proper name for such things) is that it runs just fine even on non-jailbroken devices. That's a significant advantage, at least for now.
Running a web server should be easy enough. I wrote one for WP8 (which has a subset of the allowed APIs for WinRT) and while the app *I* use it in won't be allowed in the store, other developers have taken the HTTP server component (I open-sourced it) and packaged it in other apps which have been allowed just fine. With that said, there are of course already file crypto utilities in the store anyhow... but they're "Modern" apps so you might want to develop such a server anyhow so you can use it from a desktop web browser instead.
Web cryptography (window.crypto / window.msCrypto) is brand new; it's not even close to standardization yet. I'm actually kind of shocked MS implemented it already, even if they put it in a different name. It's pretty great, though; for a long time, things like secure random numbers have required plugins (Flash/Java/Silverlight/whatever). Still, bear in mind that (as it's still far from standardized), the API might change over time.
Yep, I think of them as Trident apps since trident is what Microsoft calls their IE rendering engine, but I guess they are sort of offline web apps (which come from null domain). Being from null domain you are not allowed to use localstorage which is domain specific. You also are not allowed to make ajax requests. You just have file api and json object serialization to make do with I/O.
Another app I am working on is a kind of Fiddler app similar to http://jsfiddle.net/ where you can sandbox some simple script programs.
Kind of turning an RT device into a modern/retro version of a commodore 64 or other on-device development environments. Instead of basic interpreter you've got your html markup and script.
I have an attached demo version which makes available jquery, jquery-ui, alertify javascript libraries in a sandbox environment that you can save as .prg files.
I put a few sample programs in the samples subfolder. Some of the animation samples (like solar system) set up timers which may persist even after cleared so you might need to reload the page to clear those.
It takes a while to extract (lots of little files for all the libraries) but once it extracts you can run the html page and I included a sample program 'Demo Fiddle.prg' you can load and run to get an idea.
I added syntax highlighting editors (EditArea) which seems to work ok and let's you zoom each editor full screen.
The idea would be to take the best third party javascript libraries and make them available and even make shortcuts or minimal API for making it easier to use them. Common global variable, global helper methods, ide manipulation. I'd like to include jqplot for charting graphs, maybe for mathematical programs and provide api for user to do their own I/O within the environment.
These are just rough initial demos, and obviously open source so if anyone wants to take the ideas and run with them i'd be interested in seeing what others do. Otherwise I will slowly evolve the demos and release when there are significant changes.