zach> Duane, Did you write this plan up? Got Links? If not, care to revisit zach> the vision in a new thread on the list or a patch to The Manual? :)
Nothing wrote up - so I'll put some ideas and concepts here that could/should be put into the "developer manual" This is "vision" - nothing is cast in stone, so toss up some ideas. This is the *USERINTERFACE* part of the discussion. Another thread will be the *command ideas*. It is *UTTERLY* important that we get this API correct - otherwise we will screw this feature up big time. I cannot recommend this GOOGLE TECH TALK - enough http://lcsd05.cs.tamu.edu/slides/keynote.pdf http://video.google.com/videoplay?docid=-3733345136856180693 http://www.youtube.com/watch?v=aAb7hSCtvGw I wrote this 'out of my head' tonight, it is not clean. I've been thinking about this for quite some time. You know, we *COULD* - have OpenOCD serve out the OpenOCD manual this way too. Hmm Interesting -Duane ================================================ == For reference == I assume the reader has read: ${OPENOCD_SRC}/doc/manual/server.txt That is the starting point of this discussion. Let us assume the user has opened their web browser and points it at the "openocd built-in-web-server". What happens? What is available? Let's talk about what the user should be able to do. I want to paint a picture... ======================== Primary ======================== General Experience Goal - Ability Locally Override Location #1; The user should always be able to stuff some files in a 'project local directory' and serve those files out when the user connects to the built in web server. [ie: the directory where OpenOCD runs]. If those files are not found, OpenOCD - searches *standard* places. Example: My working directory is: "c:\myproject" the OpenOCD config file is called: "c:\myproject\openocd.cfg" I should be able to put files in: c:\myproject\openocd\ <thisdirectory> and override the system. Remember: there are often lots of html files, to many to clutter the current directory. Location #2 Users ${HOME}/.openocd/http directory Location #3 ${INSTALLDIR}/ ..... ======================== Main "HTML" page - what should "index.html" be? ======================== There should be 2 of them. (a) the main full featured one. (b) the "framed header" - that wraps around a users file. Framed Header EXAMPLE: If I create a my own "index.html" file. We should be able to "frame" that with a small title bar with some links. sort of like "google image search" - It has the original at the top of the page. This should exists so that the user always has an "out" and can get to the main default openocd page. Maybe that FRAMED header - is fancy and uses something like this: http://www.brainjar.com/dhtml/menubar/demo.html ======================== STATIC FILES ======================== We should be able to create some simple html files, for example: SPECIFICALLY: These are *directories* where all kinds of kewl things can be put. What ever you want... the examples here are *directories* http://localhost:6666/openocd/static/chip/xilinx/XC3S500E-4FG320C http://localhost:6666/openocd/static/target/st/str912 http://localhost:6666/openocd/static/board/atmel/sam3u-ek http://localhost:6666/openocd/static/dongle/xverve/signalizer Rules should be like Apache.: First - try the given name. If the given name is a directory, append "index.html" and try again. LOCATION These files should be in the "install" directory, these would be under openod/httpd/static/<whatever> the "httpd" directory should be Parallel to the TCL, and other directories under install. REQUIRED FILES index.html - for static content or index.tcl - for dynamic content } OPTIONAL (strongly suggested) various "meta-data.json". TBD - exact format, style, etc. TBD - other format, other names. Example: 'flash.json' - could describe the on-board (or on-chip) flash. Example: 'memory.json' could describe the memory map. Example: 'cpu.json' - could describe the CPU. The cpu.json file in the *board* or *target* directory might have an "http-redirect" example: openocd/static/chip/st/stm32/cpu.json - might "REFER" to "core/arm/cortex-m3.html" Likewise, the "pic32" - might *refer* to the "mips/m4k.html" These "meta-data" files - can be used by some *GENERIC* AJAX like things that create a *MEMORY* view web page, or a FLASH program page. Maybe another that can b used to *view/edit/change* cpu registers, or maybe the ARM co-processor registers. Imagine a "memoryviewer.java" - application that uses the meta data file: 'memory.json' as configuration data. TBD: Exact format and content of the *details.json* file. I think JSON is a simple easy to understand and use file format. It is also easy for us simple humans to understand, edit and read. XML is hard to edit as a human. ============================== Some GENERIC names need to work. ============================== Exact names and methodologies are TBD... this is the idea. Go back to the idea of the 'board/<boardname>.tcl files' or the "target" files - all of these *SET* certain variables. They can also *CREATE* some more vairiables that are used by the HTTP server. For example: http://localhost:6666/openocd/board Should default to the $BOARDFILE - specified in the users configuration file. If the $BOARDFILE does not exist, a simple one is created http://localhost:6666/openocd/target Could generate a list of known targets to choose from. Any *reasonable* name should be usable, for example if a CPU name exists like this: For example: http://localhost:6666/openocd/at91sam9260.cpu it should redirect you to the CPU page for that target. ============================== ALL of the above - should - use the *MACHINE* interface to get data. ============================== For example - the "fancy-memory-viewer.java" - should - know how to find and use the "memory.json" - meta data file, and communicate with OpenOCD requesting (reading & writing) memory data bytes via the Machine interface. The machine interface is to be described in more detail in a seperate email thread. =============================== How we do not want to screw this up. =============================== Anybody can create dumb dorky stick man, or cave-man quality html pages that work. You might think that AJAX is easy.. or Java, or Flash, or whatever it is. I don't really care. I'll bet many people would like to put those names on their resume - but cannot because they *know*of* the language, but do not *know* the language. So lets follow the K.I.S.S. principle, lets let the simple stuff work easily. We must not make it so that developer cannot create a caveman quality web page and be happy. That said - If somebody wants to 'abstract' a memory viewer in AJAX, ACTIVEX, JAVA, FLASH, what ever - I do not really care. Please do so. I'll give you an idea... Analog Devices VDSP has some nifty features for their DSPs, the VDSP package can read an 8bit memory buffer - and display the memory buffer as simple grey scale image. It can also display wave forms, draw graphs of data. That feature is built into the debugger. Something that fancy (and cool) probably should be written in something complex by a very good developer - but abstracting out some of the other features. That feature starts with: The base address of the buffer is (A), the Pixel Depth is (B), the image width is (C) ... and so forth. For example - would like to be able to "link to that page" passing parameters to the "image drawing" feature via the URL some how. =============================== *END* =============================== _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
