As per Nick's blog. Nice.

The screenshot above shows something i’ve been working on as a side project in my spare time and as sort of a test case for the library work i’ve been doing on the OS X front.

What you’re looking at are two versions of my Bugs application, a native OS X client for the bug tracking database we use internally to keep track of - well, not just bugs, but pretty much everything that’s to be done, including support issues, management tasks, you name it.

Both applications leverage the RemObjects SDK for OS X that i’ve talked about before (and which is in beta now, make sure to apply!), but also a very early prototype of Data Abstract for OS X which - although the class structure is still very volatile an in the early design stages - is already working very well.

What’s great is that not only do the Mac and the iPhone version of Bugs rely on the virtually identical library code in RO and DA; even the application-specific data access code is all shared between the two, with the only core difference being the presentation layer (and the amount of actual data the app fetches). I originally set out and wrote Bugs for the Mac side, and when i finally made the plunge to get an iPhone version running, it took me literally a handful of lines of code to get the basic DA data showing. Pretty cool.

On the back-end side, we have a pretty complicated “legacy” configuration. We have no less than four separate Mantis databases that stores our data. The internal database structure used by Mantis is pretty… well… odd, so accessing this directly poses a few challenges. Eventually we’ll want to move away from Mantis entirely, but doing that means replicating a lot of functionality that isn’t there yet and that we rely on the Mantis fronted application for - not something done lightly.

So we have a middle-tier server done in Data Abstract for Delphi, which uses AnyDAC to access the four (ugly) MySQL databases that Mantis provides. It also uses ADO to talk to our MSSQL server to verify user logins (we use the same user db as our website for this, which will eventually allow us to easily open access for all out customers to access parts of this data, themselves).

The four MySQL databases are abstracted to a schema that looks more closely like what we’ll eventually want our bug database to look like (once we drop Mantis altogether). The server is also leveraging Data Abstract’s Unions and the upcoming “DA HET” (short for Heterogeneous) feature to make each of the tables appear (to the client) as one entity, even though data comes from four separate back end databases.

On the client side all of this is hidden, and my DA/OS X code just deals with single tables such as the “combined_bugs_table”, etc.

As mentioned before, DA/OS X is still very much a work in progress, but i do want to share a few code snippets to show how easy it is to access data from an existing DA server, already. This is code from a class shared by both versions of the Bugs app:

First, we create the standard set of components for RO/DA data access. For anyone who has used DA on Delphi or .NET before, the class names and concepts will be instantly familiar.

msg = [[ROBinMessage alloc] init];
channel = [[ROHTTPClientChannel alloc] initWithTargetUrl:@"http://..."];
dataService = [[RORemoteService alloc] initWithMessage:msg 
                                       channel:channel 
                                       serviceName:@"DataService"];
loginService = [[RORemoteService alloc] initWithMessage:msg 
                                        channel:channel 
                                        serviceName:@"LoginService"];
rda = [[DARemoteDataAdapter alloc] initWithDataService:dataService 
                                   loginService:loginService];

Once we hold a RemoteDataAdater configured to access our server, we can fetch data - in this case we’re getting the full set of records for just one table - combined_bug_table (which, server-side, is the union of four distinct bug_tables from different database).

data = [rda getDataForTable:@"combined_bug_table"];
bin2 = [[DABin2DataStreamer alloc] initWithData:data forReadOnly:YES];
DADataTable *bugs = [bin2 getDataTable:@"combined_bug_table"];

The result is a DADataTable object that contains a recordset with the data. You can access this from code, accessing data by row and by field name or index, or use Cocoa Binding to bind it to user controls, such as the NSTableView or UITableView in the screenshots above.

Wanna know more about RemObjects SDK and Data Abstract for OS X? Drop me a mail or comment, or apply for the beta.

Enjoy!

i can’t believe all the cool stuff that's coming together at different fronts here at RemObjects, this week, so i wanted to give you guys a short glimpse at what’s brewing in the labs.

Carlo has been working on finishing off the Silverlight support in RO and DA (he blogged about it here), something we would have loved to ship in .31 but had to delay for time constraints. It’s finished now, allowing you to write in-browser Silverlight clients that can both call plain RO services, but also fetch and work with data from a standard Data Abstract middle tier server.

There’s no System.Data and DataSet on Silverlight, but full support for LINQ, so Data Abstract leverages our new DA LINQ technology that we shipped as a preview in May, to bring data across. What’s pretty cool is that this allows you to write query statements in your client that will execute on the server side – so if you write

from c in Customers where c.City = 'Berlin' select new class(c.Name, c.Address)

DA will really only fetch those records and fields from the server. Try that with LINQ to SQL, in a Silverlight client!

This is all backed by the new DA SQL engine that Alex and Carlo have been working on and which (together with Silverlight) we hope to ship in August. DA SQL on it’s own is pretty cool – as you know, Data Abstract “abstracts” away the layout of your back end databases from the schema that's presented to your application logic, as one of the many services of the middle tier.

What DA SQL does is allow you to write standard SQL code on the client side, that will be run against the *schema* that your server publishes. Mind you, this is not SQL code that gets blindly passed on to the back end database, bypassing your business logic and security; this is SQL code that will be run *on* the middle tier to determine what data to fetch, based on the names defined in your schema.

For example, the above LINQ query might (mehind the scenes) generate the following DA SQL code and send it to the server:

SELECT Name, Address FROM Customers WHERE City = 'Berlin'

note how this looks like standard code you’d run on SQL Server, mySQL or elsewhere, except this time its run in the DA middle tier. (If, for example, your schema was defined to not allow access to the Address field, the above query would correctly preserve that restriction, and fail. Similar, the the client where to send a 'DROP TABLE Customers', the middle tier would kindly refuse to comply).

In other words, the client can use the power and flexibility of SQL, without the risks (and loss of functionality) that direct exposure to the back end database would bring.

Another side effect of our Silverlight work is that Carlo and i finally went ahead and added support for asynchronous calls to RO/.NET. This is a feature we’ve been shipping in RO/Delphi for a long time, and in August, it will finally available for .NET clients, too.

Since Silverlight does not support synchronous network operations at all, this was a crucial part for getting RO and DA to run on the platform.

As you might know from previous posts here, i’ve been spending some time working myself into development for Mac OS X. I’m in the middle of implementing a port of our RemObjects (Client) SDK to OS X and am happy to report that as of yesterday, RO/OS X is running successfully not only on the Mac, but also the iPhone, both in the simulator and on the real device (i probably am not allowed to say this? ;).

The RemObjects Client SDK for OS X is a fully native library implemented in 100% Objective-C, the de facto standard language for OS X development. It’s currently in beta (apply to join!) and we’re planning to ship a “production-ready” pre-release along with our August releases (followed by an official "release" version in November).

Work has also started on the Data Abstract client for OS X, which will sit on top of RO/OS X. But it's too early to talk timeframes for that, i'm afraid ;).

Finally i’ve been putting a lot of thought into a new infrastructure for Service Discovery over the past couple weeks (inspired by some talks i have seen at WWDC), and earlier this week have started implementing our new ZeroConf based Service Discovery on the .NET/Server side. This is an early prototype right now, and aside from some basic groundwork in the core library will most likely not ship in the August releases (it should be ready for November) but i could sit here all day pressing the “Activate/Deactivate” button of the Mega Demo and see it appear/disappear in the list of services discovered on the client. ;)

Of course it goes without saying that this will be supported for all three platforms – Delphi, .NET and OS X.

So, what have you been up to this week? <g>

We've been working on some very cool things here at ro, one of which is:

What's shown here is a Silverlight 2.0 beta2 object inside Internet Explorer that fetches data using a LINQ query to a DA server using RO using DA-SQL (more on that will follow in a blog posting from Marc) fetched and sent back to the server, all running asynchronously. The grid used is the excellent AgDataGrid from DevExpress.

New in the next DA/RO for .NET will be running requests asynchronously, this will make it possible to run a RO or DA request non-blocking and get a threaded callback once the data (or exception) is ready, this will even work with DA/LINQ. Another new feature is Silverlight support in RO and DA, and DA-SQL which will be covered in the following blog posts.

I'm in the middle of preparing for my trip to northern California, leaving tomorrow for two days at a place i cannot talk about, followed by a week in San Francisco, attending Apple's WWDC, the World Wide Developer Conference.

As you know, we're slowly making inroads into expanding our RO/DA product suite to a wider range of platforms, including (but not limited to) the Mac and iPhone, so this week should prove to be very interesting, both in terms of finding out what new stuff is coming and learning more about the existing technologies, but also in terms of networking, meeting fellow Mac developers, etc.

If you happen to be at WWDC yourself, why not drop me a mail or tweet so we can meet up - chat about RO/Mac, our Mac support in the .NET/Mono products – or simply about the weather (i see we're expecting a nice 20°C, much better than the heat wave here in Berlin).

Also, even if you can't make it to WWDC: our RO|C beta program is starting, with first bits of the Mac version of RO being available. Check out remobjects.com/mac to find out more, or to sign up*.

So much for now, hope to see you at WWDC! Follow my twitter account for more up-to-date info during the conference.

We're in the middle of preparing the May round of product releases, due later this week, and i wanted to start highlighting some of the cool new features we've added in RemObjects SDK and Data Abstract.

The first item i want to highlight are Message Envelopes, an extension to the general RO messaging infrastructure that adds a lot of flexibility and enabled many cool things.

In essence, message envelopes allow you to take control of the message data that's being set out or received over the wire, and change that data, where necessary.

In the past doing this required manually handling of some events and careful coordination of what was doing done on client and server side to get things right - else client and server would no longer understand each other. Message Envelopes, instead, form an official part of the RO messaging pipeline and will be applied in a controlled fashion, allowing clients and servers to use different configurations of envelopes, for example. Message Envelopes can also be combined arbitrarily, allowing applications to take advantage of functionality provided by different envelope implementations at the same time.

One of the most obvious uses of message envelopes (and one of the most-demanded feature in the past) is their use for data security - applying some sort of encryption or signing to a message as it gets sent out, and decrypting/validating it on the way in. We've received so many requests for this, in fact, that the first message envelope implementation we ship as part of the SDK is an encryption envelope based on the popular symmetric AES/Rijndal algorithm.

Making your client/server communication secure is now a matter of dropping a component, and setting an encryption key (pass phrase) on both sides. And it works cross-platform too, between Delphi and .NET (and soon OS X/iPhone) apps.

But Message Envelopes aren't just about what we ship in the box. The AES envelope is both a great feature and a good sample, bit the real power of Message Envelopes lies in allowing users or third parties to write their own, easily adding additional data processing layers to any RO application.

To read more about Message Envelopes, check out the Wiki page at http://wiki.remobjects.com/wiki/Message_Envelopes. And stay tuned for the release of RemObjects SDK 5.0.31 later this week...

“hbf” — see it on dwarfland.com

Berlin Central Station, HDR of 23 (!) exposures — May 14, 2008

They say a picture says more then a thousand words, so here we go:

What are we seeing here?

In the background, there's the .NET version of our standard "MegaDemo" sample server that we've been shipping for years. In this case, it's running using Mono/WinForms right on the Mac, but it might as well be running on a Linux or Windows server far away.

In the front (and not out to win the Apple 2008 Design Award, mind you) is a native Mac OS X application based on what will eventually become "RemObjects SDK for Mac OS X" (or something like that). You're looking at a 100% Objective-C Cocoa application build in Xcode 3, making use of our pure Objective-C implementation of the RO client stack.

Oh, and: a similar app might of course be found running on an iPhone or iPod touch nearby, but i do not want to tempt the NDA gods by posting pictures of it, you'll understand ;).

Want to know more? let me know. we're still looking for a few dedicated testers for when this goes into beta, hopefully later this month.

“Trains” — see it on dwarfland.com

Berlin — April 27, 2008

Today, May 1, marks the third anniversary of Chrome, which was officially launched on May 1, 2005.

Chrome 1.0 was a landmark release, being the first full-featured third-party language integrated into Visual Studio. It opened up Pascal for the .NET framework, and introduced exciting new features such as Class Contracts (loosely based on Eiffel's Design By Contract, Asynchronous Methods and more.

A mere six months later, on November 7 2005, Chrome 1.5 (code-named 'Floorshow'), followed with what was essentially a major new version, despite it's .5 version number. Floorshow shipped on the same day as the .NET 2.0 framework and Visual Studio 2005, and it formalized support for these new technologies, including integration with the new IDE and language support for the new features introduced in .NET 2.0, such as generics, iterators, and more.

On August 1 2007, enjoying the longest development cycle yet, we released Chrome 'Joyride', version 2.0. Joyride brought along official support for new and emerging technologies that went beyond .NET 2.0, starting with libraries such as Windows Presentation Foundation and Windows Communication Foundation, and a wide range of extensions to the language, from enhanced nullable types support to sequences and queries and related technologies. Joyride was the first .NET language to ship production level support for LINQ, months before even Microsoft wold ship release versions of C# 3.0 and VB 9.0. Later that year, Joyride customers also saw the introduction of a new SKU which included a free copy of the Visual Studio 2008 IDE.

Finally, last month we announced the upcoming release of Oxygene, version 3.0 and with that the fourth major version of the Chrome language. On schedule for release on May 30, 2008, Oxygene revolutionizes the ways developers will be building multi-threaded applications for the next generation of hardware devices.

While a core focus of the first 3 releases has been to follow where C# and Microsoft were leading the platform, Oxygene is taking the language to the next level, beyond the "essential .NET". With the .NET platform stabilizing and the stream of new technologies coming out of Redmond slowing down, this has given our team the chance to put more focus on driving the language itself, and then parallelism features shipping this month will only be the start of that!

Thank you for your continued support and patronage of Chrome over the past 3 years — and here's to the next three years of Oxygene!

As you might have seen, this week we've announced Oxygene, the next major release of the language formerly knows as Chrome.

I'm very excited about this release as we have a lot of great things going on. Like last year when we released 'Joyride', i find myself in the position where i've been using versions of Oxygene for the better part of the past eight or ten months, so for me it's been an incremental stream of improvements and new features and minor tweaks — for you out there who are currently using 'Joyride', it will be a major step forward.

We have a set of major language extensions there that (imho) rank up there with the introduction of Generics or LINQ, with the big difference being that while Generics and LINQ have come with the framework, and Chrome was merely being a good citizen by implementing them. The parallelism stuff we're shipping in Oxygene – starting with futures, but there's a lot more it it than just those – is a different ballpark altogether, and it's something you don't get anywhere else — not in C#, nor in any other mainstream language, managed or unmanaged.

You can get a first peek at Futures on our new documentation wiki at wiki.remobjects.com/wiki/Futures.

But of course futures and related parallelism features aren't the only thing, we have more exciting additions to the language that i'll talk about more as we near release.

The first release of Oxygene, incidentally, will ship on May 30. Make sure your subscriptions are renewed in time! ;)

After analize my options to migrate from win32 to linux some Object pascal projects, and under take little test i finally get the trip. My choice is to give a try to FPC/Lazarus.

I start migrating a server from Delphi/Win32 to FPC/Linux that weekend.

The first thing i do is get the latest beta version of RO/DA libraries for FPC and make it compile under lazarus. After a little work i have RO/DA in my lazarus palette. Happiness!

RemObjects SDK palette

Data Abstracts palette

Next, i copy all my sources to a new folder, allowing to advance in my experiment with peace of mind.

Lazarus IDE have severals experts to do that help that job. One is the delphi project converter. I try that and the result was part of the project work and another forms complains about strange chars in several dfms , maybe because of the spanish language used in mostly of them.

So, i start the manual process. First converting DFM files to LFM files, and then editing all my units to make it FPC friendly.

The process is almost trivial, the main points you must have in account are:

1) Most of third parties components are delphi/windows related, so before start the process get out that libraries of
your code or you will have several headaches.
2) Activate Delphi mode in the project options. In my experience i also must do in the unit itself {$MODE delphi}
3) Add to your unit a def to change between LResources unit and windows unit. Example:

unit fServerForm;

{$ifdef FPC}
{$MODE delphi}
{$endif}

interface

uses
{$ifdef FPC}
LResources,
{$else}
windows,
{$endif}
uDAMemDataTable;

type


I put whenever i can defines.My idea is maintain a unique code base, merging that experiment with the project delphi codebase when work done.

4)Remove or embrace in ifdef the *.dfm line.

{$ifndef FPC}
{$R *.dfm}
{$endif}

5) If already no defined add initialization section including lrs files.

initialization
{$i aService_Impl.lrs}

6) Threading is a little diff,example;

{$ifdef FPC}
InitCriticalSection(aCriticalSection);
{$else}
InitializeCriticalSection(aCriticalSection);
{$endif}

TryEnterCriticalSection not implemented, use EnterCrticialSections instead.

{$IFDEF FPC}
DoneCriticalSection(aCriticalSection);
{$ELSE}
DeleteCriticalSection(aCriticalSection);
{$ENDIF}


7) Fomclose have slightly diff params.

{$ifdef FPC}
procedure TfmInputOutput.FormClose(Sender: TObject;
var CloseAction: TCloseAction);
{$else}
procedure TfmInputOutput.FormClose(Sender: TObject; var Action: TCloseAction);
{$endif}
begin
Poweroff;
end;

I think is invaluable the possibility of compile native servers, cross platforms using remobjects framework. Is worth the effort to make it works.
I love Delphi, but in the meantime, while codegears shareholders or anyone taking the path to other platforms give the needed step i will give a try to Lazarus.

What do you think? Is some of the several platforms offered by FPC a need for you in the short time?
I appreciate any comments.

“The Presidential Palace” — see it on dwarfland.com

Yaoundé, Cameroon — March 2008

For those unfamiliar with MVC, MVC stands for Model View Controller. It's a way of separating the logic (controller), from the gui (view), and the data (model). The model contains all data needed by the view, the view shows it, and if an action occurs, passes the action to the controller, which does the logic, and updates the model again, so the view can be refreshed. The advantage of this is that, even though it ends up with more code, the code is a lot more readable, as the code needed for the gui isn't mixed up with the logic needed for validation and the data isn't in the view, but separated from the view, which just has a copy, it's also a lot easier to reuse code to write a new view (for example, a web interface and a windows forms interface on the same data) as it's not so tightly bound together.

Recently I've been looking at MVC frameworks for ASP.NET to improve code quality and ease of adding features. I have looked at both MonoRail and the MVC extensions for ASP.NET. And decided that even though it's beta, the official MVC extensions for ASP.NET is the way to go.

The ASP.NET MVC extensions come with templates for C# and VB, and although we are going to provide templates for it in Chrome, we can't do that till it's finalized; these extensions change quite a bit between releases. But the project is fairly simple, it's a Web Application Project, a standalone Class Library with a ProjectTypeGuid for ASP.NET, output directory for both profiles set to Bin/. Copying the web.config file, and using the same directory structure. The MVC logic uses a directory structure like:

• Content (Folder containing anything you want to provide directly to the user, like css and images)
  
  • Site.css (Default Css style for the project)
• Controllers (Folder containing the source code for the controllers)
  
  • HomeController.pas
• Model (Data classes for the project)
• View (directory containing all the views)
  
  • Home (view for the "Home" controller)
    
    • Index.aspx (asp.net page for the "Index" action)
    • Index.aspx.pas (code behind for the index action; descends from System.Web.Mvc.ViewPage)
    • About.aspx (asp.net page for the "About" action)
    • About.aspx.pas (code behind for the about action; descends from System.Web.Mvc.ViewPage)
  • Shared (view for the master page)
    
    • Site.Master (master page for the project)
    • Site.Master.Pas (code behind class for the master page, descends from System.Web.Mvc.ViewMasterPage)
• Default.aspx (dummy page to redir to the action page)
• Global.asax (application initialization)
• Global.asax.pas (application initialization; sets up the mapping from /Controller/Action to the actual controller and view

As a project to play with this new framework I decided to tackle the long-standing issue for a web interface for our bug databases (we use a combination of MantisBT and a custom application using Data Abstract). We already had a simple login-da service for these databases, so the only thing needed was the actual web interface for it. Writing something using MVC takes practice, but it's not hard; using a Remote Data Adapter to grab the data from the server; storing it in a List<ListingItem> to pass to the view for the issue index. Another model was used for the per-issue listing. The view was kept as simple as possible, to just show the data.

Combining the power of ASP.NET, MVC, Chrome and Data Abstract, writing a web interface for the bugdb was a simple task. The web gui still needs some finishing touches to make it look good, but the coding is done, so the new bug db gui should be available soon.

Bad news. VirtualBox version 1.5.6 eats 30-45% of cpu time when you start Delphi 2007 IDE.

The problem is related to a need for the IDE of higher timer resolution than provided by the OS (Ubuntu in my case).

According to a developer of Virtualbox:

'Your guest uses a 1kHz timer, whereas your host probably just provides 250Hz resolution. so 1.5.6 uses a rather expensive way (busy waiting) to emulate proper timing. there isn't much that can be done. 1.6 (whenever it'll be out) will be slightly better, but probably not all that much. try to find out what windows app requires that 1kHz timer resolution. by default windows xp...
...just uses a 100Hz timer. '

Just to warn to Virtualbox + Delphi users. There's no workaround rigth now.

BTW, VMWare don't suffer of that 'problem'.