Welcome to TRL!

Diary of Stefan Marti's activities at IBM Tokyo Research Lab, July/August 2000


(This page expresses my personal opinions and views of my activities at TRL, and it is not an official site of TRL or IBM. This page is also not intended for public use, but only for me and my employer. The header graphic is © by TRL, though.)



before 2000/7/24
  • Installed english Windows 2000 (twice) on a clean harddrive. Had some problems because W2K didn't recognize the graphics card. Tai-san could help me with that.
  • Installed several program applications, including JDK 1.1.8 and 1.3, Aglet SDK, SocksCap32, FTP and SSH clients, etc.
  • Wrote introduction for IBM internal web pages (which I am no longer allowed to show here.)
  • Started reading book "Programming and Deploying Java Mobile Agents with Aglets" by Lange/Oshima, until chapter 6 (of 10), mainly during my train commutes.
  • Started reading JAVA programmer training book, until lesson 3 (of 11).
  • Organized my alien registration (Mitaka city hall) and bank account (Bank of Yokohama) so that IBM can put my salary on a bank account.
2000/7/25
  • Read Aglets book chapter 7, Aglet collaboration
  • Short meeting with Mitsui-san: Two things I could do:
    • Web design for the open source community. I received an email about that shortly after. Here is an example for open source project.
    • Look for interesting applications of Aglets. Ideally, find a killer app...
2000/7/26
  • Read Aglets book chapter 8, Agent Design patterns (beginning)
  • Study agent solutions from Media Lab web site (Agents group)
  • Lunch discussion with Tai-san:
    • I described my AM project; hard part is the channel selection; describe dynamic email categorization; it is NOT learning, only adaptation, though.
    • He suggests me using real Aglets beside reading the book, coding some examples. I had that in mind anyways.
  • Visited extensively Opensource.org, SourceForge.net, and other open source sites
2000/7/27
  • Read Aglets book chapter 8 (rest of chapter)
  • Started list of possible applications
  • Read JAVA programmer training book chapter 4 and 5 (skipped second half about Animations), skimmed chapter 6 (GUI) as well as chapter 7 to 11 (web related things). Studied short reference for Java syntax, including description of basic classes.
2000/7/28
  • Read Aglets book chapter 9, Inside Aglets. Very interesting is the descriptions of limitations of aglets, e.g., that static class variables cannot be serialized, and that some non-serializible objects cannot travel with the aglet, and all the issues concering class loading and transfer: that a cached class might be taken unless one uses a JAR archive, etc.
  • Introduced myself to the aglets core group mailing list of Aglets.org.
  • Installed Aglets Software Development Kit 1.1b3 successfully; test running Tahiti.
2000/7/31
  • Read Aglets book chapter 10, Security Issues (beginning)
  • Wrote batchfile to start Tahiti more easily. However, starting aglets gives a lot of error messages (java.lang.SecurityException); will have to ask Tai-san about that. Email: "Tai-san, I am playing around with Tahiti right now. Some of the example Aglets seem to run fine (Display Aglet, CirculateAglet) but whenever I start the HelloAglet example, I get the following error: 
    java.lang.SecurityException: No permission in ProtectionDomain : 
CodeSource[atp://stefan:4434/:[Ljava.security.PublicKey;@16714b]
for com.ibm.awb.security.RuntimePermission
(accessClassInPackage.examples.hello, null)
    This is followed by many other lines (that don't help me to understand the problem). Do you have an idea how to solve this? I have looked up the FAQ of aglets.org, but couldn't find anything...."
2000/8/1
  • Read Aglets book chapter 10, Security Issues (end)
  • Attended talk of Helen Wang about ICEBERG. It might be interesting to extend UC Berkeley's field trial to MIT. Would make a lot of sense since we have already a pager system working which we could modify to use as an IAP. I suggested talking more about it (she is around only next Monday and Tuesday), and then perhaps invite her to the Media Lab to see who might be interested beside Chris and our group.
  • Tai-san helped me debugging my Tahiti: It worked with simple agents, but not with more complex ones. Eventually, we found out that everything was OK (classpath, etc.), except that for some reason on my computer, in the security settings, the Runtime tab has to contain "accessClassInPackage.examples.hello.*", as well as "accessClassInPackage.examples.*". He will have to look into that on his side. Note: I also found out that there is no .props file in the current package. He will probably include that. For now, we just copied his one and renamed it to myaglets2.props, which replaces the simple myaglets.props
  • We got several Tahiti processes running in parallel on my computer, using command lines like 
    	C:\Aglets1.1b3\bin>myagletsd -port 2000
    My start.bat is not necessary anymore since we edited myagletsd to include the right JDK.
    I suggested that I play around with them, perhaps installing one Tahiti on Sandia, my PC at the Media Lab, just for fun. (Of course I have no obligation to use Nelson's HIVE instead of Aglets, just because I am from the Media Lab...)
  • We looked also at SourceForge: one thing that has to be done is writing an introduction and so forth for the CVS respository, replacing the existing files, e.g., in this directory.
2000/8/2
  • Read paper "Building Distributed Application with Aglet", by Chong Xu and Dongbin Tao. Interesting description of an aglet application with simulated stock exchange sites.
  • Read Aglets Workbench Tutorial. Very practical and useful paper describing simple applications, with a somewhat different programming style from Lange/Oshima.
  • Meeting with Mitsui-san:
    • Open source: First priority is to set up the aglet open source project. IBM and the interested parties have been talking about that for a long time, but is was never really done. One of my question was: Where does the source code actually live, is it on Aglets.org or SourceForge? We were not sure, so I asked Aaron: "Eventually, it should be on Aglets.org. Since we don't really have a large server, proper people to administer it 24/7 etc, Sourceforge is really the the tool for us for now plus it provides us with mailing lists, problem tracking etc." The aglets.org CVS repository currently contains aglet_website and aglets_packages. It probably should be there where the source code should go eventually.
      Neither Mitsui-san nor I have much experience in open source project management, so we can't lead, and we have to ask Todd/Aaron how to manage such a project. All in all, the binaries and the source code have to be well organized so that the users find their way around on this site intuitively .
    • Aglet consumer applications: A second thing would be for me to think of good applications, especially for consumer products. Mitsui-san mentions java enabled cellphones (yesterday I just asked Natalia at the Lab if she has has any experience with them; she says: not yet.) I will try to think up some good applications for cellphones. For this purpose, Mitsui-san gave me an iMode enabled cellphone (the cellphone of Takashi is PHS which does not support iMode). I used this phone during my commute back extensively. Although I do not read the Kanji characters, due to the english menu, I was able to surf the web, bookmark pages, and retrieve predigested information like weather within very short time. Aglets could be intersting in this context since the cellphone is not in contact all the time (I was wrong when I assumed that there is a permanent connection), and Aglets could be sent to a cellphone, do their job there, and then continue to another host. More about that later.
  • Continued list of possible Aglet applications.
2000/8/3 2000/8/4
  • Mitsui-san: It seems somewhat difficult to organize the opensource release of Aglets. Todd writes that he will be quite busy during the next weeks. So Mitsui-san suggest that I might just go ahead and design a pseudo web site that contains the (in my opinion) most important elements that a user might expect for a new opensource site, and then see what the others of the aglets core team say. Such a site may be lacking the sophisticated opensource elements like the ones on Sourceforge, but they can be added later.
  • After trying for a while to determine which site is the best to connect to (design and content wise), I realize that the current web page situation must be confusing for a novice user: on one hand, there is the official Aglets web page by TRL. (It is both in English as well as in Japanese, but the content does NOT seem to be the same.) The examples page though has a very different design, as if it would be apart from the rest. (Are there more such pages?) Then there is the Aglets portal. And currently, the source code is on Sourceforge, which seems to be a nice site to deposite a new opensource project.
  • Further extended application list.
  • Attended a very interesting talk by Daniel Russell, IBM Almaden, USER group. Talked to him later about his new project Portholes, which is very relevant to Nitin Sawhney's (my office mate's) project Community Aware Portals. Made contact between them, suggesting that they shold collaborate on that. It is so obiviously related, and they both would profite from it. There is no publication aboutit yet, but there will be one in fall.
2000/8/7
  • Read Sunworld article Agents to Roam the Internet. It is a quite old article (1996) that describes the mobile agent technologies up to the IBM aglets. Interview with Dan Chang, saying that many problems can be solved with traditional networking models (e.g., server-client) as well as with mobile aglets, but the added value of doing it with aglets would not be recognized.
  • Modified application list.
2000/8/8
  • Mitsui-san: Long talk about What are IBM's reasons for making Aglets opensource? My summary of the possible answers:
    • "IBM has invested a lot of resources in it, but couldn't make money out of it. Since they can't make money out of it, but realize that the idea behind mobile agents indeed is advanced, they give the technology away for free." Probably too honest... Not a good explanation!
    • "IBM makes a donation to the open source community. The mobile agent approach might get successful once it gets accepted widely, and although it will certainly not replace other networking paradigms like client-server approach, it will find its niche and facilitate certain computing tasks." Although making aglets opensource is definitively good for IBM's image, putting it that way might force too much the image of a IBM-as-politically-correct-company.
    • "The mobile agent approach can work only if it is part of a public infrastructure. Keeping it proprietary would actually prevent it from working. However, once it is public, independent programmers have to maintain and further develop it. Therefore, IBM invites the opensource community has to adopt the technology." This might work! Although people could guess that software and software concepts can made successful by choosing the right Big Player; in our context, a company like NTT DoCoMo could make the break-through for mobile agents if they wanted.
    It is almost a political issue how to answer this question, and certainly a tactical decision. The question remains how IBM wants to make money out of it once the Aglet technology would catch on.
  • Aaron would like to have my assistance on the backend code of the aglets.org website, and he suggests that I have a look at the website source; specifically the section he was working on lately, /admin.
2000/8/9
  • It looks like Aglets.org is based on JSP and the CVS repository--none of which I am familiar with. So I read some JSP and CVS tutorials (and here) as well as printed out some reference cards.
  • Although I am clear now on what CVS is (Concurrent Versions Systems), I am not clear on how to upload new files and file versions with the CVS web interface--not sure if it is possible at all. I asked Aaron about that.
  • Interesting lunch discussion with Mitsui-san:
    • Mobile computing in the future, 5 - 10 years from now: In my opinion, dedicated computers like PDAs or cellphones will disappear. Most of my personal computing--the actual processing--, will happen on my wrist watch like device (or smaller). Although the device that holds this computer will get smaller and smaller, the size of the interfaces will not get smaller since humans require certain form factors. Therefore, most of the mobile computing problems will be user interface problems. The input and output devices will be modular and communicate wirelessly with my personal wrist mounted computer. Depending on the modality, it might be a (pseudo-)telephone handset (built into two fingers of my hand: one with a microphone one with a micro loudspeaker); a holographic projection display (unfolding in front of me, showing image and video); simple wall or table mounted displays and projectors, e-paper (whenever I unfold one of it, it displays the interface to my computer), etc. Also the input devices will be modular: flexible fabric keyboards on my clothes; optically recognized typing on any surface (with any camera nearby, or with a specific camera mounted on my glasses); pseudo writing with a finger in the air, with a tiny inertial MEMS sensor mounted on the finger nail; my personal idea is "silent speaking" input devices (based on radar or ultrasonic very small sensors on my neck or implanted in a tooth, measuring a few body dimensions like angle of jaw, distance of tongue tip to lips, etc., and "reconstructing" the phonemes from this data), etc. Depending on my situation, I might choose one or the other.
    • Security: Once all information processing will be done my wrist mounted device, the problem of security comes up. What if we loose this small device? Where would we store backup data? One possibility would be to use redundant storing concepts, similar to RAID concepts: all my personal relevant information is stored at several different locations with different storing technologies (optical, magnetic, atom based, etc.) Whenever data changes, the other places are updated. If one device is lost or destroyed, the remaining storing locations rebuild it from redundant information. This works only if we have trusted encryption technology and secure wideband wireless network connections.
    • Where would we store important personal information? One possibility would be to store it in our own body. An obvious solution would be to engrave data with low power lasers on our fingernails (similar to 3D barcodes today), but that allows only for static snapshots. Another possibility would be to store it in our bones, be it by implanting a high density storage chip with a ultra-low range, ultra-high bandwith wireless connection, or by modifying the bone structure on a microscopic level. The ultimate solution would be to store this data directly in our brain, using the natural brain storage mechanisms--which we unfortunately don't know yet! (A version of this idea is described in the movie Johnny Mnemonics.)

I was away Thursday August 10th and Wednesday August 11th.

2000/8/14

  • Mitsui-san suggests a two-stage approach:
    • Stage one: make source code open, but read-only. Furthermore, upgrade the project to open source, which means terms and conditions change. Particularly, stage one includes:
      • One page for open source project, which includes:
        • One paragraph: What are Aglets?
        • One paragraph: What is an open source project?
        • Link to license
        • Link to source code repository
        • Link to latest binary build
        • Perhaps statement of future plans
      • Changes on www.aglets.org site.
      • Changes on TRL's aglets web pages to make the content consistent with this open source activity.
      • A link in IBM developwerWorks site.
      • TRL home page announcement.
      • Media announcement: article for IBM developwerWorks, and maybe for independent media channels as well.
    • Stage two: make it possible to upload contributions from contributors. Additionally, projects like Java 2 migration, and incorporating more standards.
2000/8/15
  • Prepared a simple web page according to Mitsui-san's suggestions from yesterday. The graphic design is just a suggestion. (I currently do not have the graphic software tools to push the design further easily.)
2000/8/16 2000/8/17
  • Interactively with the Aglets coregroup, refined the Aglets Open Source web page. Still have to implement the information I found on the Aglets Open Source Petition site.
  • Tai-san will eventually put the binary code on Sourceforge, and then I will link it from there instead of from TRL's Aglet web site. Also the Aglets code for Java 2 should go there, in a separate directory.
2000/8/18
  • Spent a long time trying to install an aglet host on a Media Lab machine to test Aglets behavior when traveling across the whole globe, in real. Because the network was flaky in the afternoon, it took quite some time to do all the changes, e.g., to downgrade a machine remotely to Java 1.1. The remote control software VNC is partially Java based (at least the viewer in a browser), which of course is problematic when one installs new Java versions... I got help from Nitin in Cambridge/U.S.A. who powercycled the machine manually for me...
  • Was partially successful, until at 3pm the network connection was lost completely and did not come up again until the evening. Will continue next week.
  • Updated the Aglets Open Source web page and the Aglet Applications page.
2000/8/21
  • In order to upgrade the TRL Aglets web page, got a snapshop of the HTML code from Tai-san. Although it would be possible to just edit the HTML code manually, it will be difficult to make major changes since the design is quite complex and I don't have graphical tools to "reverse engineer" the images manually. Therefore, I will try to use the same tools as the original developer of the site.
  • On first sight, it looked like the page was built with IBM HomePage Builder 2001 V5.0.3 for Windows. So I downloaded the trial version of this software and installed it. However, Tai-san told me that the original Web designers probably had different tools, and he just imported the pages to HomePage Builder, so there are no graphic templates available. I will try to use the existing graphics (adjusting their HTML width and height) to make space for the necessary content changes.
  • Tai-san: after long talk I realize that the IBM Aglets team has a lot of good ideas about what could be done next to advance the Aglets project. It would be good to have such a list on the Aglets Open Source web page. Here are a few items:
    • Splitting up Tahiti to separate host server from GUI, so that the GUI can be started when it is necessary, independent from the server.
    • Making the Aglets host server an NT service so that it can run continuosly in the background (I would love that).
    • Then, since the Aglets host daemon is not very stable, add a "watchdog", a special small daemon (service) that can start, stop, and restart the Aglets host daemon. This watchdog can be controlled remotely via TCP/IP or similar.
  • I will propose a modification of the TRL Aglets web page, probably the front page. Then I will show it to Mitsui-san and Tai-san. Furthermore, we have to decide on where the Aglets Open Source web page has to go eventually, perhaps as a link from Sourceforge? Not sure though.
2000/8/21
  • After having figured out the design of the TRL Aglets site, I prepared two example front pages that include the new announcement, as well as omit several obsolete parts of the original front page:
    • Suggestion one, the news that Aglets are Open Source gets its own little "window".
    • Suggestion two, the announcement of Aglets as open source is integrated in the rest of the news.
2000/8/22
  • Went through all Aglets.org pages and wrote down the possible changes that reflect the new situation with Aglets:
    • Front page: insert short newsflash at the very beginning, perhaps animated GIF
    • News: initialize this section, add several paragraphs about OS and Aglets
    • Download: change Aglet Packages links, ad two paragrpahs text
    • Main Menu bar: in the middle, remove GIF link to TRL Aglets download section
    • Resources: add a short page at the very beginning which acts like an abstract, a very short intro, or a summary
    • About/Petition: has to be modified, not sure how to keep the information further below. Perhaps a historical section on how Aglets became an OSS?
2000/8/23
  • Modified TRL Aglets pages further, suggesting the following changes: Here are the actual changes. The same have to be done on the equivalent Japanese files:
    • File "index.html" (currently saved as index_new.html)
      • Added big red frame with Open Source announcement in uppper left corner.
      • Changed "Latest releases" section (adding "IBM" in title, removing the Fiji sentence, changing the order of the versions, etc.)
      • Deleted whole "Aglets in Real World" frame.
      • Modified "Announce" section (changing it to Announcement):
        • Changed Java2 announcement.
        • Deleted last two announcements about Version 1.1 and 1.0.3
      • Changed brown menu graphic on top right (topics_home3e.gif), erasing the obsolete third entry ("Aglets in Real World") (GIF saved as topics_home3e_new.gif)
      • Minor optical changes and fixes.
    • File "faq.html" (currently saved as faq_new.html)
      • Additional first question (and answer) about difference between IBM Aglets release and Open Source Aglets release.
      • Changed the answer to "currently available for ASDK" by adding link to Aglets.org.
2000/8/24
  • Installed WinCvs 1.0.6 (WinCvs 1.1 did run only at the beginning, but then crashed and was not bootable anymore). WinCvs run after quite some modifications (e.g., had to find and add manually tcl81.dll).
  • Installed more tools, e.g., ExamDiff Pro.
  • Finally, was able to check out the aglets_webpage. Modified several files (according to yesterdays suggestions), and commited them.
  • Since Aglets.org is based on JPS pages (JavaServer), I couldn't view the modified pages properly. I installed Jakarta Tomcat, but still wasn't able to view the pages.
From 2000/8/25 until the end of my stay
  • By making the Aglets.org changes live, the Aglets are now officially Open Source! The TRL site has still to be updated. My suggestions, the Front page and the FAQ page, are still local. From the IBM open source developers zone, there is already a link to Aglets.org.
  • Updated the Aglets.org web page serveral times with WinCvs. It was not simply working all the time, because the TRL DNS server did quite often "forget" the entry of web1.aglets.org. Usually, in such a case, I would just do a Nslookup and replace the name with the actual IP address (as I did with SSH, FTP, and VNC sessions), but WinCvs somehow associates the host name with a directory. Therefore, I could log in, but a subsequent command like "Update Folder" failed because WinCvs was looking again for the original host name. I couldn't figure out how to change this behavior. As a solution, we told the network settings to look for a specific DNS server (as opposed to the one given by DHCP), and from then on, it worked most of the time.
  • In order to run the Aglets.org page locally and to view the JavaServer based pages, I installed also the Apache Jserv package, but the web pages still didn't display. According to Tai-san, this was probably due to the fact that Aaron has some Java classes included that I currently don't have. I have asked Aaraon about that.
  • Kept trying to let travel Aglets around the world... I successfully set up a Tahiti server on Sandia.media.mit.edu (with VNC remote control). Again, I had to make the changes in the security settings: the Runtime tab has to contain "accessClassInPackage.examples.hello.*", as well as "accessClassInPackage.examples.*". I could then create local Aglets on Sandia, but still was not able to dispatch them from Tokyo to Boston. It is clear that Aglets dispatched from Tokyo to Boston cannot return home on their own, because the firewall at TRL won't let them back in. The only possibility would be to retract them actively. Unfortunately, the same is true for Aglets sent from Boston to Tokyo, since the Media Lab has also installed recently a somewhat less rigid, but still effective firewall. Therefore, the Aglets sent from Tokyo were not allowed to get to Sandia in the first place, and my experiment of letting the Aglets cross real space failed. Another problem would be that my computer at TRL is running DHCP, and therefore has no DNS entry and no real host name. To send Aglets from somewhere else, one does not only have to overcome the TRL firewall, but also know the current IP address of my computer, since it has no real host name. Additionally, in order to let the daemon know the host name (which is not possible for my computer at TRL anyways), one has to start the server with the modified props file. Therefore On Sandia, starting the Aglets server was done with the following command: 
    	C:\Aglets1.1b3>bin\myagletsd.bat -f my_aglets2.props
  • Following the general Open Source model (e.g., Apache Tomcat), I suggested to create different Agelt packages, perhaps three classes:
    • Release Builds: stable, working builds--these builds are "as good as it gets."
    • Milestone Builds: somewhat stable but not crystal-clean. One can have confidence in them, but they are buggy and should only be used by advanced users who want to explore future product direction or take advantage of new features.
    • Nightly Builds: very unstable. One shouldn't trust them. They are for developers who are helping to develop the technology and want "the latest bits." To use at your own risk!
    Unfortunately, the Java2 version (which would be a Milestone Build) cannot be published yet. Furthermore, Aglets.org is not yet set up to create nightly builds. And perhaps it is too early anyways, since the whole Open Source community still has to get going!



Send me some comments! Stefan Marti Last updated August 30, 2000.

Copyright © 2000 by Stefan Marti and IBM TRL. All rights reserved.