dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pnet-developers] Future of resgen


From: Carl-Adam Brengesjo
Subject: [Pnet-developers] Future of resgen
Date: Fri, 21 Jan 2005 05:17:32 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041209)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have been working, as some of you know, on resgen and to make it work
with loading, e.g., a bitmap from a .resx file and then generate a
.resources file with the data, but I have come to realize something.

Currently, resgen ONLY support string data. It doesn't even try to
identify the type. And the work needed to be done to simulate
Serialization and a managed context (assemblies, types etc) is just
too much to be seriously considered, IMHO.

Example, a bitmap in .resx is loaded using TypeConverter, but is it
realisticly possible to implement a type converter for allt the types a
user might eventually want to embedd in a .resx? Or even something like
a object implementing ISerializable (the object/type itself provides the
data to be used in serialization), that is impossible without a runtime
engine.

Primitive data types is doable, not much work needs to be done. But all
other object types isn't possible in my opinion.

The work I've already done enables resten to be extended to support more
types-- as long as it doesn't involve serialization. So only primitive
types should be supported in pnet/resgen. But if anyone want to give it
a try (native serialization), please, go ahead.

So, question is, should we proceed to extend pnet/resgen, which I
consider is a no-go (except for other primitive types), or write a
managed version?

My vote is on extending pnet/resgen to cover primitive types, and
writing a managed version to cover everything.


So, comments and/or thoughts?


Regards, Carl-Adam Brengesjo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFB8IJcgLIl8/jW7bMRAmhDAJ43ugUC090L0xCkQVLIOZflqNjlWgCeJHxp
DJuah7zTp+wKAeQbkVJAhb0=
=itqL
-----END PGP SIGNATURE-----


reply via email to

[Prev in Thread] Current Thread [Next in Thread]