[Dillo-dev]Task list & priorities
Hi there, Here I'm attaching the draft for the priorities list we're working on with Sebastian. Note that [1] Parsing of XML empty tags (e.g <script/> as <script></script>). is already done! and I'm working on the parser to avoid memory leaks with bad HTML, to be able to get the doc tree from parsing (XML well formedness validation and hopefully good for CSS too). Let's name this one as: [1] Orthogonalize the parser (leaks, XML, CSS) And here are a few to add to the list too: [ ] Login messages for the ftp dpi. [ ] Bookmarks dpi "sort" function. [ ] Back/Forward for #anchored links. -- Cheers Jorge.- PS: Please conside all of these works when I'm sending delayed answers :-P
On Sat, Nov 06, 2004 at 07:11:12PM -0300, Jorge Arellano Cid wrote:
Hi there,
Hello!!
[3] Preferences dpi. [3] Handling of configuration data.
<Sebastian> I'd regard this as one task (from the user's point of view). Here, I'd rather focus on designing a solid base rather soon, on which future extensions may be build on. It is not clear yet, how this will look like at all, but supposed (as an example), that dillo manages the configuration data (not a dpi), communication with configuration dpis should be considered, but made possible later.
(Except the feature, on which Daniel Fairhead is working.)
<Jorge> Configuration data also needs some sync. For instance, dillorc, cookiesrc, cacherc, <dpis>rc. Maybe having a common format and a powerful preferences dpi makes sense at this stage.
ok, i will take ahold if this one if no-one objects. i would love to see this done, as it makes doing lots of other things much, much simpler in the future, especially the cache thing. since the cache thing is now going to be pretty much on hold until after the CCC study, i need something to do in the mean-time. ;) i don't think it should be too relevant as to if configuration is handled by a dpi or by dillo proper, since it's just a matter of what part things ask to get their configuration data from, as they should never have to look at a config file themselves. it should be fairly trivial to rewrite how things ask for their config. keep in mind i have yet to look at the dpi system at all, so i could be completely wrong with that assumption. i'm assuming that being able to offer a configuration API would allow a layer of abstraction that would hide the internals of how things are actually done as pertaining to aquiring configuration data. i've got a higher priority project currently on my plate, but the way things are looking, it shouldn't be but a couple more days until i'm done with it, at which time i will study the dillo code at great length and evaluate which would be the easier way (for me at least) to handle this.
[3] Make cookies into a dpi server.
<Jorge> Procrastinated from a long time ago. This solves the problem of only the first Dillo instance (and its child windows) having cookies enabled. Now that cookies work better (with 302 redirections) this problem will be more evident.
i think it may be to my advantage to tackle this task first, as it will give me a much greater understanding of the dpi structure. that should certainly make a configuration dpi a very simple task to get completed.
[5] GUI dpi for downloads.
<Sebastian>
i agree 100% with you on this, however.......
<Jorge>
i think of such annoying sites as sourceforge that do all sorts of wonky things with the url you send it that wget just doesn't properly grok. while i certainly prefer to copy the url and give it to wget myself, sometimes that just isn't practical. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.
Hi Brian, On Sat, Nov 06, 2004 at 11:44:48PM -0500, Brian Hechinger wrote:
On Sat, Nov 06, 2004 at 07:11:12PM -0300, Jorge Arellano Cid wrote:
Hi there,
Hello!!
[3] Preferences dpi. [3] Handling of configuration data.
<Sebastian> I'd regard this as one task (from the user's point of view). Here, I'd rather focus on designing a solid base rather soon, on which future extensions may be build on. It is not clear yet, how this will look like at all, but supposed (as an example), that dillo manages the configuration data (not a dpi), communication with configuration dpis should be considered, but made possible later.
(Except the feature, on which Daniel Fairhead is working.)
<Jorge> Configuration data also needs some sync. For instance, dillorc, cookiesrc, cacherc, <dpis>rc. Maybe having a common format and a powerful preferences dpi makes sense at this stage.
ok, i will take ahold if this one if no-one objects. i would love to see this done, as it makes doing lots of other things much, much simpler in the future, especially the cache thing. since the cache thing is now going to be pretty much on hold until after the CCC study, i need something to do in the mean-time. ;)
Great! Now we have a man in charge of it.
i don't think it should be too relevant as to if configuration is handled by a dpi or by dillo proper, since it's just a matter of what part things ask to get their configuration data from, as they should never have to look at a config file themselves. it should be fairly trivial to rewrite how things ask for their config. keep in mind i have yet to look at the dpi system at all, so i could be completely wrong with that assumption.
There's at least one big advantage of having the preferences done in a dpi server instead of Dillo (but some more come to mind :). If you have two instances of Dillo which one is in charge of preferences? If you have a dpi running, and the user exits from Dillo what happens with preferences. If there're two Dillos running we'd need to provide for Dillo to Dillo communcation. How do we handoff preferences from an old Dillo that exits to a newer instance? etc. On the plus side, a Dpi server solves those problems. The issue with this approach is how to communicate with Dillo, but we already have the dpi protocol (dpip). Which is flexible and extensible and can make this communication happen (for instance as the "chat" command in bookmarks). The rc files could all reside in ~/.dillo/ and there would be no race conditions on them (as now with cookies). For instance a simple approach (and simplicity is an asset) is something like: str = a_Prefs_get("font_factor"); if (str) ff = strtol(str); g_free(str); a_Prefs_get() could do it task by sending a dpi command: <dpi cmd='get_preference' name='font_factor'> the answer can arrive packed like this: <dpi cmd='answer' to_cmd='get_preference' name='font_factor' value='1.25'> and recovering "value" with a_Misc_get_attr_value() is trivial!
i'm assuming that being able to offer a configuration API would allow a layer of abstraction that would hide the internals of how things are actually done as pertaining to aquiring configuration data.
Sure.
i've got a higher priority project currently on my plate, but the way things are looking, it shouldn't be but a couple more days until i'm done with it, at which time i will study the dillo code at great length and evaluate which would be the easier way (for me at least) to handle this.
Read doc/Dpid.txt. It's a good introduction. You can also have a look at Cfg.txt inside: http://www.dillo.org/misc_files/cfg-test-0.0.3.tar.gz but this is more advanced than what we need now. Anyway it may show some light of things we may require in the future. Sebastian can provide more feedback on that part although I'd regard that as part 2.
[3] Make cookies into a dpi server.
<Jorge> Procrastinated from a long time ago. This solves the problem of only the first Dillo instance (and its child windows) having cookies enabled. Now that cookies work better (with 302 redirections) this problem will be more evident.
i think it may be to my advantage to tackle this task first, as it will give me a much greater understanding of the dpi structure. that should certainly make a configuration dpi a very simple task to get completed.
I'd advice to try to use the 'chat' command for this task, and asking me when in trouble. Getting inside the CCC at this stage is not a good idea.
[5] GUI dpi for downloads.
<Sebastian>
i agree 100% with you on this, however.......
<Jorge>
i think of such annoying sites as sourceforge that do all sorts of wonky things with the url you send it that wget just doesn't properly grok. while i certainly prefer to copy the url and give it to wget myself, sometimes that just isn't practical.
This is very simple, but needs some time. For instance, adding login information messages to the FTP dpi is a matter of calling dup2 on stderr, and dup2 into a pipe for stdout, that way the former stderr can be parsed, the pertinent 'send_status_message' commands sent into the pipe, followed by the actual data. The same applies for downloads, and there's a prototype. -- Cheers Jorge.-
participants (2)
-
Brian Hechinger -
Jorge Arellano Cid