September 2002 Archives
September 27, 2002

Emacs customizations for MacOS X

Emacs

Here are some customizations I've found necessary to make to have a nicer integration of Emacs for MacOS X.

Download the redo package and place it somewhere in the load-path of Emacs. Add the following in your ~/.emacs file:

(setq mac-command-key-is-meta nil)
(global-set-key [(alt v)] 'yank)
(global-set-key [(alt c)] 'kill-ring-save)
(global-set-key [(alt x)] 'kill-region)

(global-set-key [(alt q)] 'save-buffers-kill-emacs)

(require 'redo)
(global-set-key [(alt z)] 'undo)
(global-set-key [(alt shift z)] 'redo)

These settings essentially bind some frequently used commands on MacOS X like copy, cut, paste, undo, redo and quit to their Apple key equivalents.

If you're interested in starting to use Emacs on MacOS X, let me know. If there's enough interest, I can make a binary package of them and share my .emacs customization file.

Posted by ovidiu at 06:48 PM |

Creating applications with Mozilla

Open Source

Brett Morgan:


While mooching through Creating Applications with Mozilla I noticed something very cool in chapter 12. Remote Mozilla Applications - where a mozilla application is pulled at run time from a web server.

This is really cool! I still dream of an RSS aggregator integrated in Mozilla, which has the ability to subscribe to Weblogs you visit while browsing. The current process is too cumbersome, copy the RSS feed URL and manually enter it in the RSS aggregator. You almost forget to do it.

Now that I switched to NetNewsWire, I was thinking I could write a simple AppleScript and invoke it from Mozilla to subscribe to the RSS feed in NetNewsWire. A specialized Mozilla application would be able to capture the URL and invoke the AppleScript, but NetNewsWire is not AppleScript enabled :(

Posted by ovidiu at 04:32 PM |

Emacs on MacOS X

Emacs

I found David Wright's Weblog doing a search on Google for how to link MacOS X and Linux via NFS. While reading it, I came across a link to a port of Emacs 21 to MacOS X. Really cool! I'm downloading it right now, and since is a bit slow I thought I might enter this note here. It would be great if I can have Emacs running natively on MacOS X, even if it's not XEmacs.

Posted by ovidiu at 02:51 PM |

XML scripting and XSLT

XSLT

Ugo Cei comments on my previous comparison of native XML scripting with XSLT:


Maybe the procedural model is more understood, but is this a reason to use an inferior solution? Using goto is easier to understand than structured programming, but Dijkstra showed us that goto is harmful. Structured programming is easier to understand than object oriented programming, but does anyone really advocate throwing objects out of the window? Procedural programming is easier to understand than functional programming, but would you choose a procedural solution over XSLT? I would almost never.

Then James Strachan responds:


XSLT is great for processing an XML document in a declarative way and outputting a new XML document result. If you wanna process the XML in a different way, like work with database, invoke web services, work with your business objects then using XPath with a real programming language (say a procedural OO one) is often a good idea.


I don't think there's one size fits all uses when it comes to processing XML, its quite a broad topic.

Many times I found myself as developer of various frameworks that work with XML in great need to access XML nodes. For that you definitely some ways to access and manipulate the document's data model, and integration between the programming language (Java here) and the XML representation is crucial. JXPath has been very successful in doing just that.

However I don't think a developer of an application should use such low level features. Instead, higher level frameworks should be used instead, since they hide all the low level complexities of the XML data model, and allow for nice ways to process the XML.

SOAP-RPC libraries are a good example of that, there's no need to understand the format of the messages that go back and forth. Cocoon is another example of framework which gives a wide range of options for processing various XML sources, without having to go into the details of manually parsing or explicitly manipulating XML nodes.

Posted by ovidiu at 02:51 AM |

Object/Relational bridges

Java

Gerhard Froehlich writes:


This OR/Bridge thread is amazing and it's was me who kicked it off. I learned so much last days. Blogs are really great. Lot of smart people around who have the same problems every day and I think we get them all solved.

I feel the same here, there are many new things I've learned by following this thread. Next thing to do: find out more about Hybernate, and what is the difference between it and Apache OJB.

Posted by ovidiu at 02:23 AM |

Why map:aggregate is harmful

Cocoon

Steven Noels explains the difference between <map:aggregate> and the cinclude transformer in Cocoon when composing aggregated XML documents, like HTML pages for portals. Subtle differences which I didn't realize so far: great stuff, thanks Steven!

The basic difference is in the way the generation of the final aggregated page happens. The <map:aggregate> is a sitemap construct, which essentially places the included XML content from the different source inside some XML elements. Here is an excerpt from Cocoon's samples sitemap entry:

  <map:match pattern="news/aggregate.xml">
   <map:aggregate element="page" ns="http://foo.bar.com/myspace">
     <map:part element="news" ns="http://foo.bar.com/slashdot" src="cocoon:/news/slashdot.xml"/>
     <map:part element="news" ns="http://foo.bar.com/moreover" src="cocoon:/news/moreover.xml"/>
     <map:part element="news" ns="http://foo.bar.com/xmlhack" src="cocoon:/news/xmlhack.xml"/>
    </map:aggregate>
    <map:transform src="stylesheets/news/news.xsl"/>
    <map:serialize/>
   </map:match>

With <map:aggregate> you need to apply an additional transformation step to translate the resulting XML document to (X)HTML.

In contrast cinclude is a transformer which processes a template file with placeholders for the content to be inserted instead. Here's a simple file which could be fed to the cinclude transformer (assume the file is named aggregate.xml):

  <page>
   <title>A Simple Page using Content Aggregation</title>
   <content>
     <para>
      <cinclude:include src="cocoon:/news/slashdot.xml" element="slashdot" ns="http://foo.bar.com/slashdot"/>
     </para>
     <para>
      <cinclude:include src="cocoon:/news/moreover.xml" element="moreover" ns="http://foo.bar.com/moreover"/>
     </para>
     <para>
      <cinclude:include src="cocoon:/news/xmlhack.xml" element="isyndicate" ns="http://foo.bar.com/xmlhack"/>
     </para>
   </content>
  </page>

The equivalent sitemap entry would look like (adapted from Cocoon's samples sitemap):

  <map:match pattern="news/aggregate">
   <map:generate src="file/aggregate.xml"/>
   <map:transform type="cinclude"/>
   <map:transform src="stylesheets/news/news.xsl"/>
   <map:serialize/>
  </map:match>

In the case of the cinclude transformer, we can avoid the last transformation by modifying our aggregate.xml to contain only the necessary (X)HTML html, body, table and/or div elements to give structure to the aggregated XML/XHTML documents.

Posted by ovidiu at 01:52 AM |
September 26, 2002

Switch to NetNewsWire

Weblogs

I decided to switch to NetNewsWire Lite, as the number of entries generated by my own XSLT-based RSS aggregator became too large to follow on the main Weblog page. NetNewsWire does a very good job so far, I like it!

Posted by ovidiu at 11:52 PM |

BEA's native XML scripting and Jelly

Web services

James Strachan continues his comparison of native XML scripting in BEA Workshop and Jelly. (XML native scripting originally pointed out by Carlos Perez).

I would compare the native XML scripting extension of JavaScript with XSLT, rather than with Jelly. With the BEA XML scripting solution you can manipulate XML the same way you can do it with XSLT, except that you do it in a more procedural form. Gone is the pattern matching approach, and the very functional style of XSLT programming. In is the procedural, more understood processing model, at least by the vast majority of Java and JavaScript programmers.

It is debatable whether we need a new syntax to be able to integrate XML data types in a normal language. Most of the access and manipulation features described in the article can be achieved by using something like JXPath or Jaxen. Both these libraries access nodes or nodesets in an XML DOM representation using XPath, and return them for further manipulation. I found this to work very well in all the cases I needed such access.

The inline XML assignment in the native XML scripting (does it have a name?) is IMO just a syntactic sugar, and it actually promotes dangerous mixing of content and logic. Pretty soon we'll start seeing scripts which mix XML markup with logic to fill in the template, similar to what JSP allows you to do today.

Another thing which is worrisome is the XML processing model introduced by the native XML scripting. One of the great things about XSLT is the pattern matching oriented programming model, the so-called rule-based programming. Of course, you can still do procedural programming in XSLT using <xsl:for-each> and <xsl:if> to iterate over the children list, but that is something to be avoided since it ties the stylesheet to a particular structure of the input documents. The rule-based programming model is no longer available with the native XML scripting solution, not unless is explicitly coded by the programmer.

As far as Jelly is concerned, my gosh, it's amazing! Last time I checked out Jelly was way back in December 2001, when I started working on Anteater, a functional testing framework for SOAP clients and services. Jelly seems to be now a complete programming language with an extensible syntax (and semantics of course) based on XML! I'm not sure whether this is good or bad, I simply hate the XML syntax for anything which is procedural. We'll see what it will evolve into, and especially how people use it! Good luck with it James!

Posted by ovidiu at 01:38 AM |
September 24, 2002

RSS 2.0 support in my XSLT news aggregator

Weblogs | XSLT

I've implemented support for RSS 2.0 in my XSLT-based news aggregator. It turns out to support it I only had to copy the RSS 0.92 templates, and add the proper namespace. Really simple! Since I was here, I also added a fairly simple fallback mechanism, so if a new RSS is invented, the aggregator simply displays the information specified in the subscription.

I've placed all the files in a CVS repository, together with my MovableType templates.

Posted by ovidiu at 02:46 AM |
September 23, 2002

100,000 threads in less than 2 seconds!

Linux

Gerhard Froehlich points out to a new major development in the 2.5 series Linux kernels: the Native POSIX Threading Library, sponsored by Redhat, is able to start up and destroy 100,000 threads on a dual Pentium III Xeon 450MHz in 2.3 seconds, with more than 50 threads running at the same time! The previous 2.5.31 kernel Previously the same test took 15 minutes: wow!

Posted by ovidiu at 11:26 PM |

Cocoon get together again

Cocoon

It looks like after all I'll be present at the Cocoon get together meeting on November 19th. I'll make a presentation of the control flow layer and how it could be used to build applications more easily, using strong separation between business logic, content, presentation and page flows within the application. Obviously I'll make that presentation available online. I also hope to have a realistic demo for it.

Posted by ovidiu at 04:30 PM |

Copyright and licenses

Open Source

There was a lively discussion on cocoondev@outerthought.org few days ago about copyright and licenses. I post this reply to Nicola Ken Barozzi, as I think is of a greater interest.

When we are talking about software, no matter is free software/open source or proprietary, there are two aspects of it we are interested in. The first one is the copyright holder, and the second one is the license.

The copyright holder is the person or organization who holds the rights for the code. The copyright holder decides what is the license the code should have. It can even release the code under two or more licenses. For example he/she can release the code under an open source license, and at the same time release it under a commercial, proprietary and more restrictive one. There are many reasons one can do this, I don't want to get into this right now.

The fact that you own the copyright allows you to release the code under any license you want. That's why in the past people where reluctant to give away they copy rights to organizations such as FSF. One example is Linus with with his baby, Linux. He chose to keep the copyright for himself, and let others contribute code to Linux without having to assign their copy rights to him. Linux is effectively owned by hundreds of people or organizations. I think this works marvelously: nobody can decide to make their piece of code proprietary and use in a closed project: if they do it, they have to use that code outside the context of Linux, which in many cases is useless. GPL prevents them from incorporating other people's code in their closed proprietary project, unless they obtain the approval of the other copyright holders to do this, or the whole product is released under GPL. GPL allows you to do this, and such it has a great advantage over any other free software/open source license.

If you're the copyright holder, you can still release your code under a proprietary license, even if it's also released under GPL. This is the case with SGI's XFS filesystem, which is a proprietary piece of code still in use in SGI's Irix operating system. The fact that SGI is the copyright holder allows them to do this. What they cannot do is take other people's contributions to XFS, released by them only under GPL, and incorporate them in their proprietary code (You can still do it if the copyright holder releases that code under your own proprietary license). This is very tricky, so the motivation for you as a copyright holder to open source the code in the first place must be clearly made. This is usually done with mature projects, which can only marginally benefit from other people's contributions. What you get instead from the community is more exposure, in terms of user testing and, of course, a lot of marketing visibility.

To alleviate the issue of not being able to incorporate other people's changes in you code, various organizations came up with their own licenses. One of the most well known such license is Mozilla Public License. This license explicitly states the code must remains open source, no matter what changes another organizations make to it. This has the great advantage the code under such a license can be incorporated in any proprietary projects by anybody in the world, and that any changes made to it are published under MPL, thus are open source as well. Unlike GPL, MPL does not restrict in any way the license of final product you're incorporating the code into. This is a great advantage for enterprises, since they are not restricted in any way.

LGPL is very similar to MPL, but it enforces you as a product vendor not only to include the libraries or jar files of the LGPLed product, but also to include your own libraries used to generate the final product. The reason for this is to preserve the rights of the LPGLed code, which can be modified and re-linked against the proprietary libraries to obtain the final executable.

The last license I'm discussing about here is the Apache Public License, a variation of the well known BSD license. Licenses in this category allow anybody to take the code released under such a license, modify it and incorporate it into their proprietary project, without any restriction. The license does not prevent you from doing this. This type of licenses are very beneficial to companies like Microsoft, since they can benefit from the work of thousands of developers without contributing anything back.

Being a copyright holder allows you to release the code you hold the rights for under any combination of licenses. Giving away this copy right, you effectively loose the ability to incorporate it into your or somebody else's proprietary project , under a more restrictive license. FSF however gives you back such a right, once you assign the copyright to them, while ASF does not.

Posted by ovidiu at 11:25 AM |
September 18, 2002

MacOS X 10.2.1 released

Apple

I'm installing it right now on my machine. Let's see if some of the issues I've seen are fixed by this update.

Another update delivered by Apple's Software Update is for iTunes, which is now at version 3.0.1.

Posted by ovidiu at 10:51 PM |

Sam Ruby broke my RSS aggregator

Weblogs
Sam Ruby changed his RSS feed again, which apparently breaks my RSS aggregator that you see on the right hand side of this page. I've removed him from my subscriptions list! At least until I have some time to figure out what's wrong with the XSLT-based RSS aggregator I've written.
Posted by ovidiu at 04:35 PM |
September 17, 2002

MacOS X Jaguar update

Apple

Mark Pilgrim has a story about an upcoming update to Jaguar. The list of changes, captured from a document posted by Apple, and since then retrieved from their site, shows several changes to the basic operating system. Among them, it appears Jaguar will finally be able to burn Windows CDs, a feature missing from MacOS X for an incredibly long time.

My favorite is placed in the category Networking and Mail Enhancements:

Addresses a situation in which, if the connection fails when transferring email to your computer via your network or an Internet connection, all mail not transferred is lost.

Ops! It's funny how serious bugs are suddenly presented as enhancements.

Posted by ovidiu at 11:46 AM |
September 11, 2002

Remembering 9/11

Random

Very sad day today. Silence, no postings during the day.

Posted by ovidiu at 01:21 AM |

Even free, iCal isn't worth the price

Apple

Apple released iCal.

RandomMaccess has a comment: Even free, iCal isn't worth the price [via Matt Croydon].

The most compelling feature is the ability to publish your calendar online on a WebDav-enabled Web site, and share it with your peers. However I couldn't yet do it on the Apache instance running on my Powerbook, because of some WebDav setup issues I have.

In the first five minutes of playing with iCal, I found this bug. The window which pops up when you select Calendar -> Publish... consistently forgets to ask the URL of the site to post to, if the first time you use it you cancel the action.

To reproduce, choose Calendar -> Publish..., select Publish on a Web server. Don't enter any data, and select Cancel. Repeat the same steps again, you'll notice you're no longer asked for a site where to publish your calendar. To get back the text field to enter your URL, restart iCal.

Posted by ovidiu at 12:40 AM |
September 10, 2002

Mozilla as a Web services platform

Open Source | Web services | Weblogs

Salon has an interesting article about Mozilla as platform for developing applications [via Slashdot].

It's so refreshing to see Mozilla being positioned as a platform, and not just as yet another browser. It will be interesting to see how much this platform will take off. It certainly makes sense to have Mozilla applications built around Web applications running on remote servers, since it would be easier to manage the remote content using a richer, desktop-like interface. Weblogs are a good example of such an application.

To be really successful, the Mozilla platform will need to penetrate the enterprise market. Mozilla could probably succeed better as a development platform for enterprise applications, than as yet another browser the IT departments have to support.

Having backend enterprise applications accessible as Web services would probably make Mozilla's job a lot easier, since there's no need to load proprietary code in the Mozilla application. Thus the only thing to be implemented in such an application will be only the user interface, which interacts with the backend Web services-enabled system.

Posted by ovidiu at 07:38 PM |

Cocoon meeting

Cocoon

Steven Noels of Outerthought officially announced today the Cocoon get together meeting.

I'm still trying to figure out whether I can make it. It should be a very good opportunity to meet face-to-face most of the Cocoon developers, and get some ideas what are people working on.

Posted by ovidiu at 11:58 AM |
September 09, 2002

Jaguar's Mail.app not very effective fighting spam

Apple

Mail screen capture showing lots of junk mail. Click to get a larger image.

It looks like the Mail application that ships with MacOS X 10.2 Jaguar is not very effective in identifying my junk mail. After more than 2 weeks in training mode, I still get lots of junk. Today for example, after a normal week-end, when I came back to office I had 160+ messages, out of which only 3 were legitimate. As you notice in the attached picture, Mail was unable to mark most of them as junk.

Microsoft Entourage had similar problems in identifying junk mail, so I'm happy with neither of them.

The only successful spam killer I've found is SpamAssasin, a collection of Perl scripts to be used in conjunction with procmail. I used to run this tool very successfully on my Linux desktop, until I moved to MacOS X. In MacOS 10.1 it was impossible to run procmail with Mail.app, because of the mailbox format used by Mail.

A more MacOS-X-ish solution would be to have the ability to have Mail.app run an AppleScript when email is received. Mail.app doesn't have this ability however. Interestingly enough, Microsoft Entourage has it. In many respects, Entourage feels a more mature application than Mail.app.

Posted by ovidiu at 02:27 PM |

More on Bruce Perens departure from HP

Open Source

New York Times has an article about Bruce Perens' departure from HP. As I reported earlier, Bruce is no longer with HP.

The main reasons for his departure though seem to be related to the Microsoft baiting Bruce is doing. His latest actions are against Microsoft's backed industry group, the Initiative for Software Choice. This group is persuading governments all over the world to use highly priced proprietary software instead of equivalent open-source ones, which are freely available. Bruce started Sincere Choice to counter the Microsoft led initiative.

Posted by ovidiu at 09:29 AM |

Model-View-Controller in Cocoon using continuations-based control flow

Cocoon


I've finally had time to finalize some changes to the control flow layer of Cocoon, which should make it more usable. I've also wrote a simple application that makes use of these changes and shows how the control flow layer is supposed to be used. I also plan to write some real documentation on how to use the control flow layer. Before then however, I'll write here some quick thoughts on how this works. At some point I'll take these and transform them into a real document.



Model-View-Controller

With the control flow architecture in place a Cocoon Web application is split in three different conceptual layers, using the well-known Model-View-Controller (MVC) pattern:

  • Model: the business logic, e.g. Java classes which implements the meat of your application.
  • View: the collection of the XML pages and XSLT stylesheets that give a visual representation to your business objects. In Cocoon the pages used in the View layer can be simple XML files or XSP pages that use the JXPath logicsheet. More on this later.
  • Controller, which is coordinating the sequence of pages being sent to the client browser, based on the actions taken by the user. In Cocoon, the Controller is a specialized engine which uses a modified Rhino JavaScript implementation which supports continuations as first class objects. From a user (really a developer) perspective, the Controller is nothing else than a collection of JavaScript files running on the server side.

The general flow of actions in an application which uses the control flow is as described below.

The request is received by Cocoon and passed to the sitemap for processing. In the sitemap, you can do two things to pass the control to the Controller layer:

  • you can invoke a JavaScript top-level function to start processing a logically grouped sequences of pages. Each time a response page is being sent back to the client browser from this function, the processing of the JavaScript code stops at the point the page is sent back, and the HTTP request finishes. Through the magic of continuations, the execution state is saved in a continuation object. Each continuation is given a unique string id, which could be embedded in generated page, so that you can restart the saved computation later on.

    To invoke a top level JavaScript function in the Controller, you use the <map:call function="function-name"/> construction.

  • to restart the computation of a previously stopped function, you use the <map:continue with="..."/> construction. This restarts the computation saved in a continuation object identified by the string value of the with attribute. This value could be extracted in the sitemap from the requested URL, from a POST or GET parameter etc. When the computation stored in the continuation object is restarted, it appears as if nothing happened, all the local and global variables have exactly the same values as they had when the computation was stopped.

Once the JavaScript function in the control layer is restarted, you're effectively inside the Controller. Here you have access to the request parameters, and to the business logic objects. The controller script takes the appropriate actions to invoke the business logic, usually written in Java, creating objects, setting various values on them etc.

When the business logic is invoked, you're inside the Model. The business logic takes whatever actions are needed, accessing a database, making a SOAP request to a Web service etc. When this logic finishes, the program control goes back to the Controller.

Once here, the Controller has to decide which page needs to be sent back to the client browser. To do this, the script can invoke either the sendPage or the sendPageAndContinue functions. These functions take two parameters, the relative URL of the page to be sent back to the client, and a context object which can be accessed inside this page to extract various values and place them in the generated page.

The second argument to sendPage and sendPageAndContinue is a context object, which can be a simple dictionary with values that need to be displayed by the View. More generally any Java or JavaScript object can be passed here, as long as the necessary get methods for the important values are provided.

The page specified by the URL is processed by the sitemap, using the normal sitemap rules. The simplest case is an XSP generator followed by an XSLT transformation and a serializer. This page generation is part of the View layer. If an XSP page is processed, you can make use of JXPath elements to retrieve values from the context objects passed by the Controller.

The JXPath elements mirror similar XSLT constructions, except that instead of operating on an XML document, operate on a Java or JavaScript object. The JXPath logicsheet has constructs like jpath:if, jpath:choose, jpath:when, jpath:otherwise, jpath:value-of and jpath:for-each, which know how to operate on hierarchies of nested Java objects. Historically the namespace is called jpath instead of jxpath, we'll probably change it to the latter before the next major release.

A special instruction, jpath:continuation returns the id of the continuation that restarts the processing from the last point. It can actually retrieve ids of earlier continuations, which represent previous stopped points, but I'm not discussing about this here to keep things simple.

Going back to the sendPage and sendPageAndContinue functions, there is a big difference between them. The first function will send the response back to the client browser, and will stop the processing of the JavaScript script by saving it into a continuation object. The other function, sendPageAndContinue will send the response, but it will not stop the computation. This is useful for example when you need to exit a top-level JavaScript function invoked with <map:call function="..."/>.

The above explains how MVC could be really achieved in Cocoon with the control flow layer. Note that there is no direct communication between Model and View, everything is directed by the Controller by passing to View a context object constructed from Model data. In a perfect world, XSP should have only one logicsheet, the JXPath logicsheet. There should be no other things in an XSP page that put logic in the page (read View), instead of the Model. If you don't like XSP, and prefer to use JSP or Velocity, the JXPath logicsheet equivalents should be implemented.

Basic usage

As hinted in the previous section, an application using Cocoon's MVC approach is composed of three layers:

  • a JavaScript controller which implements the interaction with the client

  • the business logic model which implements your application

  • the XSP pages, which describe the content of the pages, and XSLT stylesheets which describe the look of the content.

In more complex applications, the flow of pages can be thought of smaller sequences of pages which are composed together. The natural analogy is to describe these sequences in separate JavaScript functions, which can then be called either from the sitemap, can call each other freely.

An example of such an application is the user login and preferences sample I've just checked in CVS:

http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/flow/examples/prefs

This application is composed of four top-level JavaScript functions: login, registerUser, edit and logout.

The entry level point in the application can be any of these functions, but in order for a user to use the application, (s)he must login first. Once the user logs in, we want to maintain the Java User object which represents the user between top-level function invocations.

If the script does nothing, each invocation of a top-level function starts with fresh values for the global variables, no global state is preserved between top-level function invocations from the sitemap. In this sample for example, the login function assigns to the global variable user the Java User object representing the logged in user. The edit function trying to operate on this object would get a null value instead, because the value is not shared by default between these top-level function invocations.

To solve the problem, the login and registerUser functions have to call the cocoon.createSession() method, which creates a servlet session and saves the global scope containing the global variables' value in it. Next time the user invokes one of the four top-level functions, the values of the global variables is restored, making sharing very easy.

Even if you don't need complex control flow in your application, you may still choose to use the MVC pattern described above. You can have top-level JavaScript functions which obtain the request parameters, invoke the business logic and then call sendPageAndContinue to generate a response page and return from the computation. Since there's no continuation object being created by this function, and no global scope being saved, there's no memory resource being eaten. The approach provides a clean way of separating logic and content, and makes things easy to follow, since you have to look at a single script to understand what's going on.

Posted by ovidiu at 03:03 AM |
September 08, 2002

Jaguar and per session SSH agent

Apple

Richard Johnson points out SSH Agent by Xander Schrijen, which could be used to access a global SSH agent process per login session, which keeps track of all your identities. This is a replacement for SSHAgentServices, which as I reported earlier no longer works on MacOS X Jaguar.

The only caveat with this application is that you need to have it running all the time during your login session for the SSH agent to be running. But other than is a perfect replacement for SSHAgentServices, and a clean one since is not dependent on Apple's loginwindow.app, which seems to refuse loading of custom written plugins.

I've spent half a day trying to see why SSHAgentServices doesn't work, and I believe loginwindow.app is doing some nasty checks to avoid loading custom written plugins. Neither SSHAgentServices, nor a little plugin I wrote as a test were loaded successfully inside loginwindow.app.

Is MacOS X becoming one of those poor platforms from Apple that Joel is talking about?

Posted by ovidiu at 11:48 PM |
September 04, 2002

WikiWiki plugin for MovableType

Weblogs

Les Orchard has a plugin for MovableType which allows entries to be edited using a WikiWiki text format.

Posted by ovidiu at 01:24 PM |

Games banned in Greece

Random

In a terrifying move, the Greece government banned all electronic games, either running on game consoles, mobile phones or computers, according to CNET:

The blanket ban was decided in February after the government admitted it was incapable of distinguishing innocuous video games from illegal gambling machines.

Google has a cached version of the English translation of the law, according to gameland.gr, which seems to be down.

The ban seems to cover even innocent games like tetris, and those that come bundled on any operating system. It's really absurd! Whatever the motives behind such a law, the solution is just too drastic and abusive.

Posted by ovidiu at 09:34 AM |
September 03, 2002

MacOS X on x86 hardware?

Apple

Apple reportedly has builds of MacOS X 10.2 running on Intel compatible hardware. Don't hold your breath yet, as explained in the article and as I previously noted, Apple needs to move its customers to use the new Cocoa APIs instead of the Carbon ones, which provide an easy migration from the old MacOS. The business model has to also change, which is a major undertaking.


But a switch to Intel or Advanced Micro Devices Inc. processors is probably not in the cards for tomorrow's Macs, sources said. Such a move would require a massive revision of Apple's closed hardware architecture and a fundamental rethinking of its business model, which is founded on tight integration between its proprietary system software and hardware. Apple would have to also coax most of its third-party developers to rewrite their applications from the ground up in the company's Cocoa application environment. (Most major vendors have instead tuned their applications to Carbon, a set of Mac OS X-compatible APIs originally culled from the classic Mac OS and rooted in the PowerPC architecture.)

Posted by ovidiu at 05:47 PM |
 
Cool stuff
  Arduino TinyWebServer: part 3 and part 2
Search
More from me
Picture gallery
Admin
Copyright © 2002-2016 Ovidiu Predescu.