A possible PND-system replacement

[KickAss]

I could wrote a .desktop file parser in every language i know in half an hour. Xml on the other hand (hint bash is one of them )

The point is: you wouldnt need to. Theres XML parsing libraries for pretty much each and every language ever created.

Personally i never liked XML very much. But why would we want to reinvent the wheel? (P)XML creation aint rocket science.


A new parser could prove handy for given reasons tho.

 

[milkshake]

Would the meta data on the desktop file be able to things such as associating file types like the pxml does? And how well would a flat config style meta data list handle that?


xml and json are both excellent for cross platform and cross language data transfer/storage especially with all the support they have which desktop files don't have.

 

[RuneIV]

Just wanted to say good job slaeshjag.

I really like your proposal. I'm looking at the code and might contribute.

 

[slaeshjag]

File type association is in the end handled by the very desktop files that are emitted. So, whatever format you store it in inside the package, it has to come out in the desktop file anyway. Same goes for translated names and descriptions, all that will end up in the .desktop file in the end.

 

[milkshake]

What about multi app pnd's ?

 

[slaeshjag]

Multiple desktop files.

 

[urjaman]

Unrelated, but an idea.... so sorry for armchair dreaming here.

So... you're (or are planning to) "spawning" shell wrapper scripts for command-line things and rm'ing them as the db's leave? [NB. 1 make that place a tmpfs in the final version... just a /bin folder thats in the path but also is on a tmpfs. ... this was unrelated to my idea... ]

Could you have it just copy an executable from the zip if the thing is very small or wishes to have some helper available without the lag of mounting?

 

[slaeshjag]

The dbp-system keeps track of which executables are exported by which packages, so it'll clean those up as packages comes and goes.

As it is right now, that would be kind of annoying to implement copied binaries. As part of the start-up routine for dbpd, I nuke all stale wrappers. For that, I depend on a magic comment on line 2 to determine if it's created by dbpd or not. I guess a workaround would be to have it on a tmps and assume dbpd will never crash or be restarted, but that's kinda ugly.

 

[milkshake]

There are going to be executables in the zip? I thought the zip was for meta data and the application and it's data in the iso or squashfs archive?

 

[slaeshjag]

There's no executables in the zip. The metadata contains the path in the SquashFS of executables to export though.

 

[sebt3]

I could wrote a .desktop file parser in every language i know in half an hour. Xml on the other hand (hint bash is one of them )

The point is: you wouldnt need to. Theres XML parsing libraries for pretty much each and every language ever created.

Any pointer for "libraries" to parse XML in these languages :- all the shell families (*csh, b*sh, zsh, *ksh)

- awk

There is none. But every single PND include some shell.

Ho and good luck trying do create such libraries in any of them while my 30mn work limit to parse .desktop files in any of them still stand (including slaeshjag extentions)

 

[KickAss]

I could wrote a .desktop file parser in every language i know in half an hour. Xml on the other hand (hint bash is one of them )

The point is: you wouldnt need to. Theres XML parsing libraries for pretty much each and every language ever created.

Any pointer for "libraries" to parse XML in these languages :
- all the shell families (*csh, b*sh, zsh, *ksh)


- awk


There is none. But every single PND include some shell.


Ho and good luck trying do create such libraries in any of them while my 30mn work limit to parse .desktop files in any of them still stand (including slaeshjag extentions)

Why not cat the .xml file and hand it over to awk like so:

cat list.xml |awk 'BEGIN{RS="<Name>"} NR>1 {print substr($0,1,index($0,"</Name>"))}'

This isnt actually my code, tho.

Yeah i get your idea and you're right of course.


Im just saying that the data that needs to be parsed is rather limited in our case (in the pnd system as well as in the next iteration) and xml works fine. At least thats my understanding.


Of course a new parser could probably easily be developed since the data that needs to be parsed is so limited. If someone wants to go that road, go for it. Im not sure yet if its worth the hazzle.

 

[milkshake]

with multi app pnds and pxml all the data is on one file but with this concept multiple desktop files would need to be parsed.

 

[Neelix]

Im just saying that the data that needs to be parsed is rather limited in our case (in the pnd system as well as in the next iteration) and xml works fine. At least thats my understanding.

That's not really an argument either way.  You could say exactly the same thing about the .desktop files.   Come to think of it almost every argument in this thread so far for an xml based solution has been something the .desktop based solution does just as well or is something I wouldn't actually consider an advantage.  (eg  having to write a specific tool to format the data into an easily readable format)   So far the only question about what format to use this thread has brought to my mind isn't "why not use XML?"  it's "Why bother with XML?" 

- Neelix

 

[milkshake]

Xml brings benefits I.e. You can validate xml against a schema xsd file, you can transform xml into various formats (probably even into a .desktop) using xslt.


Both xsd and xslt are also written in xml which is neat.


I can only think of these a positives over plain .desktop files.


Plus xml is very well suited to structure data in a logical format.

 

[KickAss]

Im just saying that the data that needs to be parsed is rather limited in our case (in the pnd system as well as in the next iteration) and xml works fine. At least thats my understanding.

That's not really an argument either way. You could say exactly the same thing about the .desktop files.


- Neelix

Which is what i did in the next sentence. dot desktop files could work just as well. But the system and tools need to be designed first. I just wanted to express my doubt about the true benefit compared to the work that needs to be done first. If people think its worth it and want to make it work im all ears (and eyes actually).

 

[pmprog]

Any pointer for "libraries" to parse XML in these languages :

- all the shell families (*csh, b*sh, zsh, *ksh)

- awk

http://stackoverflow.com/questions/4984689/bash-xhtml-parsing-using-xpathThis says there's an xpath program which you can use to query xml documents. Don't have a linux instance around atm to check if it's in by default

 

[WizardStan]

- all the shell families (*csh, b*sh, zsh, *ksh)

xmllint and some string looping

- awk

I'm not sure that would be appropriate even if there was. The thought of even trying terrifies me.

 

[levi]

Xml brings benefits I.e. You can validate xml against a schema xsd file, you can transform xml into various formats (probably even into a .desktop) using xslt.


Both xsd and xslt are also written in xml which is neat.


I can only think of these a positives over plain .desktop files.


Plus xml is very well suited to structure data in a logical format.

Theoretically XML does all these things, but in practice these benefits are very rarely seen, at least in my experience.  I take it the repo uses a PXML schema to validate submissions, but I don't actually know where to find it, and wouldn't have anything installed that I know of to test a PXML file against a schema currently.  I don't know that I even have any way to test an XML doc as well formed beyond trying to parse it into a DOM in Perl or something.

XML is a pain to write well.  Theoretically we should be falling over good open source XML editors, to ensure your stuff is at least well formed but the only ones I know of are proprietary.

Programatically it's well suited for machine to machine information interchange, as it's well supported in most languages since Java, and solves a lot of problems of character sets, escape sequences and the likes.  But the DOM API is clunky in almost anything but Java (where everything is clunky so it doesn't matter).  Most of the time I ended up writing a SAX parser in less time than I'd have needed to use DOM, but you can't easily validate that way AFAIK, so you have to cope with all invalid data situations.  I've not tried data binding, which seems an interesting way as long as it's still reasonably performant though.

And the less said about XSLT the better IMO.  I once oversaw a project to convert XML into installer scripts using XSLT, and the output was so overblown that I only ever gave the code a cursory glance, though it's fair to say the code has worked for as long as it was needed perfectly, I just don't know how.

 

[urjaman]

The dbp-system keeps track of which executables are exported by which packages, so it'll clean those up as packages comes and goes.

As it is right now, that would be kind of annoying to implement copied binaries. As part of the start-up routine for dbpd, I nuke all stale wrappers. For that, I depend on a magic comment on line 2 to determine if it's created by dbpd or not. I guess a workaround would be to have it on a tmps and assume dbpd will never crash or be restarted, but that's kinda ugly.

I was expecting more like a flat-file db on tmpfs of the exported wrappers. An alternative would be to have a tmpfs folder that contains all of them and only all of them and just nuke it on daemon start.

--

But I'm okay with you not breaking that meta / binary (=zip/sqfs) barrier

Alternatively, are you looking to eventially 'cache' the mounts for a little while (atleast when using these wrappers)?