[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold writes:
> The problem with this approach is that it's very platform specific,
> as binary approaches have always been.
Not if its based on a platform agnostic binary data serialization, see
below.
> I suspect Sun's approach will
> work well for Java. But will it work well for C? What's the
> performance impact when byte orders need to be flipped when
> deserializing? I doubt very much Sun can get an order of magnitude
> improvement on all platforms of interest, much less with all
> documents of interest. In fact, I wouldn't be surprised if their data
> optimizations for Java actually decrease performance for programs
> written in Perl, C, or other languages.
>
For the record, there's nothing Java specific about the encoding. Data
is encoded using ASN.1 Packed Encoding Rules (PER). ASN.1 was around
long before Java, PER is not based on Java serialization. I would
expect a C based ASN.1 PER library to perform as well as a Java
equivalent.
> I very much suspect Sun's proposal would have the "accidental" effect
> of strongly encouraging developers to use Java. Of course, it will
> work if you use C# or Perl, but it will work better with Java.
Of course Sun will strive to make its implementation best-of-breed, the
old Sun mantra "Cooperate on standards, compete on implementation"
still applies. If this encourages more developers to use Java then
that's great. However, there's nothing in the fast web services work
that skews the performance characteristics in favor of Java over other
languages.
Regards,
Marc.
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
|
