Slashdot Mirror

I found a copy of "draft-leach-uuids-guids-01.txt" here.

• ReiserFS provides a way that you should be able to efficiently build a DB hierarchically as a set of directories and files, where files are the "leaf nodes" that contain field data, and where you might use symbolic links to represent secondary indices.

  It would provide pretty "weak typing" of a sort of TCLish style where "everything is a string, sort-of."

• In contrast, MySQL provides a way of representing "structured data," with "strongly typed fields." And the filesystem view provides a convenient way of looking at that data.

There are probably a lot of useful applications out there that wouldn't care much about the distinctions. That probably parallels the way that a lot of applications out there don't really care that MySQL does not satisfy the ACID properties or offer triggers, foreign keys, or other such things.

It also might be regarded as parallelling the way that Lisp-like languages have "strongly-typed data" with dynamic typing, which is a bit the way ReiserFS might be used, whilst "MySQLFS" looks a bit more like the "static strong typing" of ML/Haskell. Which is a rather weaker analogy...

In any case, the distinctions between ReiserFS-as-DB and MySQLFS are fairly strong. MySQLFS looks a lot, by the way, like the NameSpace concept in Casbah.

I'd focus on data storage first; without that, it really doesn't matter what kind of pretty GUI face you put on the front of it.

One of the "keys to success" on both PalmOS and Newton was that of having a whole lot of the system based on persistent data structures, e.g. where "everything is stored in a database." (Newton called this soups. )

Thus, when you're "juggling data," all you're juggling is a record here and there, rather than the traditional Unix "filesystem" approach where it's a whole file full of data being juggled, with attendant increases in risk of failure, in time consumed, and in storage required for "scratch space."

There is something arguably similar available on Linux; take a look at Casbah, which maps data in various forms onto a directory hierarchy.

Given a sound way of storing information, it then makes sense to proceed to provide useful abstractions for accessing that information; PalmOS has been successful foremost because they were open to developers wanting to use the system, from whence comes the hordes of useful and not so useful Palm apps.

It is not at all obvious to me that the up and coming would-be dethroners of PalmOS have taken seriously the task to get data storage right; most of the Linux-based systems seem pretty loose about this.

I would like to favor Linux-based PDAs, but based on what I see so far, I see little reason to consider an iPAQ running Linux over the alternative of upgrading to a TRGPro with 8MB of RAM.

It sounds to me like they're recreating what IIOP provides, and with the added cost that you need to encode data in the rather wasteful XML format.

I half figure that someone will eventually build an "XML over IIOP" scheme that will allow compressing it.

The Casbah project's LDO provides another alternative.

It sounds to me like they're recreating what IIOP provides, and with the added cost that you need to encode data in the rather wasteful XML format.

I half figure that someone will eventually build an "XML over IIOP" scheme that will allow compressing it.

The Casbah project's LDO provides another alternative.

I looked into the SIF when it was first announced months ago. We went over the license on Technocrat, and quickly realized that it wasn't open source at all.

When you look at how MS intends the ZIS to be used, the end-user software that anyone but the techies see isn't intended to write or read data natively in the SIF format. There are agents to translate from the proprietary data formats to/from SIF. After things get through the agents into SIF form they get processed by the ZIS.

So why bother with SIF at all? The agents are clearly where the important work is to be done. If we want to do something similar, why bother with porting some MS code and be limited by their license? We already have an XML spec called EduML that does pretty much the same thing. There are OSS educational programs being written to use EduML as their native data format. If we were to use something like the Casbah Project as the backend, all we'd need to do is write a little glue and agents for whatever non-EduML software we wanted to play with our efforts. And it would all be OSS.

If you're at all interested in this sort of thing, come take a look at SEUL/edu and help us get Linux and OSS more widely accepted and used in education!

Doug Loss

• It'll not be scalable enough.

  For instance, there will need to be a "compression extension" because XML is verbose, thus making messages large.

• It'll not be robust enough.

  Thus requiring an extension so that messaging can be managed by MTS and/or MSMQ, or WTCTNY (Whatever They Call Them Next Year).

• It'll not integrate well enough with whatever tools they're using next year.

None of the technologies are inherently a problem:

• SOAP doesn't seem to be massively worse than XML-RPC although it's probably not as good as Casbah's LDO system.
• MTS is probably not as good as Encina or Tuxedo, but is doubtless better than the nonexistent TP monitors not being deployed in departmental/workgroup systems
• MSMQ may not be as good as Tuxedo, or as open as Isect, and is merely derivative of IBM MQSeries, but doesn't seem to be too bad, again being better than the asynchronous messaging systems nonexistent in non-big-iron systems

The implementations may be run-of-the-mill and derivative, but they're based on pretty good ideas, which is why it's been pretty easy for MSFT to market them.

What is a massive problem is that what gets deployed next year is liable to be massively incompatible with what is available this year.

In a sense, the only hope for developers that use the stuff is if there is some sort of "mass disconnect" where MSFT gets split into MSFT-1, MSFT-2, MSFT-3, ... and this results in the tools deployed having an extra year to stay vaguely stable...

• Between the KDE Two Conference material and KDE 2.0 Technology Overview, it appears that there is a proliferation of messaging systems.

  It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?

  What comes to mind are:

  • Lightweight Distributed Objects (LDO), submitted as an IETF draft, and
  • HTTP-SOAP, also an IETF draft
• Has any consideration been made of using some of the configuration libraries and data formats already available, such as:
  • ACAP, which has an IETF draft
  • libPropList which is used by GnuStep and OpenStep as well as by WindowMaker.
  • Ted Tso's .ini file reader?

It is such a shame when new formats have to be designed and managed, when debugged code already exists to implement these sorts of things.

[noting that no real requirements were mentioned, this is just a general answer]

Many people have suggested straight sockets, and, for the most part, I agree with them. Taking one example, telnet-based protocols have shown to be some of the most versatile, scalable, and approachable protocols around (FTP, SMTP, IRC, NNTP, HTTP, ...).

If you're looking for a more structured protocol, Lightweight Distributed Objects (LDO) is a modular set of specifications for building structured protocols. LDO also includes modules for basic RPC and distributed objects.

-- Ken MacLeod
ken@bitsko.slc.ut.us

There is at least one alternative to SOAP, notably written by people who understand, use, and write free software: Lightweight Distributed Objects (LDO).

http://casbah.org/LDO/>