pgeorges wrote:
Hi!
>> This is a stable SuSE? Or some of this Open-Ever-Beta
>> stuff? That is: could it just be a bug in SuSE? Probably
>> solved by some of their updates?
>>
> I use SLED 10.1, supported by Suse. I also checked on Windows
> (ActiveState Tcl) and tdom is present.
So it is a bug in SuSE's packages?
>> Anyway could you please check wether this is a singular
>> problem on your setup? Probably by compiling tDOM from
>> source? You're a lot more in this tcl-stuff then I'll ever
>> be...
>>
> What I mean is that on some OS / distro, tdom will not be present. So
> the user will have to fetch this one which is not always easy to do for
> everybody.
Point is that as far as I understand the few lines of doc
I've for tDOM and all I read about XML in tcl:
- All xml-parsing seems to fall back on tDOM at some point.
- tDOM should be present in a normal distibution, probably
as a separate package (as in Debian which uses a very fine
package splitting, much finer than you know it from your
SuSE, hence I did not wonder that I had to aptitude it)
but it is, as far as I understood it, "standard" and
should be available everywhere and easily.
- compiling tDOM might be PITA as, as far as I understood
it, it's just a wrapper for expat, using libexpat, libxml,
libiconv and stuff. All the libs are not needed once tDOM
is built but to build it they are, so you've to set up a
whole bunch of tools which themsevles have some deps plus
you'll not only need libxml e.g. but also the libxml-dev.
I did not check it out in detail what's required to build
tDOM follwoing all this deps, but as they start with 3
libs, iconv beeing some stuff from Gnomes backend, well...
Now I could do some hackish code and regexping down all
messages I get from Xfcc. BUT that would tailor the code to
the current state and if the messages change you'd have to
redo the parser. Probably you'll even have to do it in a way
for each service due to the flexibility of xml inside, I did
not check this. Additionally xml is only then easy to parse
if one can rely on a decent parser, otherwise it's pretty
complex and one has to handle a lot of specialities. Ok, for
our usage one could do that, as Xfcc's xml is actually
pretty simple. For Xfcc at the state today. (Let them invent
attributes and it might change a lot...) But it would IMHO
get quite a bit of code and would certainly not be good for
maintainability.
That's the reasons why I prefer a solution that includes
<place your favourite here> XML-XPath solution for tcl. I
tried tclXML, but that fails as it requires again tDOM to do
the actual interpretation. (I've won nothing if I could
extact the path...)
Now with the code added the internal support will be
disabled if tDOM fails, and it will throw a message once you
open the config dialog telling the user the reason why it is
disabled. It'll try to allow enabling it later on again.
This seems fine to me as one could still use some external
tool.
The other way I could go is to literally translate
Xfcc-Receive.pl and Xfcc-Send.pl into tcl and use them as
external script who require themselves tDOM and ::http. One
would then have to call them as external apps, but as far as
I understood you in our input engine discussion this
generates some problems on CE, so I thought you'd prefer an
internal solution instead of external calls. Thats why I did
an ::Xfcc-namespace in the correspondence.tcl.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
