Firefox 3 bookmarks extension

Write an extension for Mozilla/Firefox to read/write bookmar

Tue, 06 Sep 2005 17:57:26 +0000

Write an extension for Mozilla/Firefox to read/write bookmarks directly to/from a Horde server.

Bounty added: http://horde.org/bounties/details.php#trean_f

Wed, 20 Dec 2006 22:03:13 +0000

Bounty added: http://horde.org/bounties/details.php#trean_firefox_addon

We should first make sure Trean can handle the field "keywor

Sun, 04 Feb 2007 22:34:35 +0000

We should first make sure Trean can handle the field "keyword" (this is probably quite easy) and maybe include support for "separator" too. And maybe a way to sort the bookmarks.

Sorting is implemented now (though I guess you mean custom s

Mon, 05 Feb 2007 00:11:02 +0000

Sorting is implemented now (though I guess you mean custom sorting; that's possible too but not done yet); do you happen to know if the keyword field in Firefox expects a single keyword, or a comma-separated list, or what? I'm not sure what to do about separators - I don't think it'd make sense to display them as part of the main Trean interface, but if it'd need to be stored, we can probably do that.

Yes, I meant custom sorting. The "keyword" field seems to

Mon, 05 Feb 2007 08:32:22 +0000

Yes, I meant custom sorting. The "keyword" field seems to accept any string, but it only works if it is a single word. (So you are allowed to type in "foo, bar baz", but then neither word will work as a keyword for that bookmark). For separators I had an idea of implementing them as some kind of "special" bookmark. I believe that would be the easiest to code. It would add them to the database just as any other bookmark, but with a special name or some other flag to distinguish them from normal bookmarks. That way you would not have to add a lot of special code to deal with them. This depends on custom sorting ofcourse, as we would need that to make the separators show up where we want, and not grouped together at the top or bottom of the list... We could then display them as a simple

or something in the Trean interface if we want that at a later stage.

Here's the first (beta-ish) release of my solution to this b

Mon, 09 Apr 2007 05:55:49 +0000

Here's the first (beta-ish) release of my solution to this bounty. I've oh-so-creatively named it TreanMarks (better suggestions welcomed.) It comes in two pieces: a patch to server-side Trean, mostly to add RPC calls, and a Firefox extension implemented in javascript. Features ================= o 100% JS means it should be cross-platform! (or, as much so as XmlHttpRequest is) o A TreanMarks menu next to the Bookmarks menu o Support for bookmark/folder deletion, adding bookmarks (by delegating to Trean itself in a popped-up browser window), and bookmark/folder properties (also delegated to Trean) o Locally caching the bookmarks and then "synchronizing" via RPC, to cut down on time spent down-/up-loading TODOs ================= o Look into 'compressing' server response XML (for RPC), by not indenting prettily. I don't think this is even offered through the PHP extension :( But I think it may cut down on wait times considerably. o Pre-fetching bookmarks on browser load o Caching bookmarks to disk, for "offline" access (if that makes any sense) or just quicker pre-fetches on browser load Bugs ================= o Each browser window keeps its cache separately, so that means your Trean bookmarks have to be loaded "into" each window. I'd imagine this might be simple to fix, I just haven't got around to it yet. Request for Comments ================= I've actually been wondering if there's a different, much better way to go about this. Are there already (preferably HTTP-based) protocols to do stuff like this? Perhaps Atom? Anyways, I'll get this code out there since I've already invested a bunch of time into it. ;) Files ================= o treanmarks.diff is a "cvs diff -Nur HEAD" of all my Horde-side changes. o treanmarks.xpi is a Mozilla extension installer package. It's a renamed ZIP file, so you can get at all my extension source in there. (By the way, anyone have a 32x32 Trean "heart" icon?)

another attachment P.S. Sorry, I haven't written much do

Mon, 09 Apr 2007 06:00:25 +0000

another attachment P.S. Sorry, I haven't written much documentation yet... Configure the extension in Tools -> Add-ons. Find the "TreanMarks" entry and click Options button. From there things will probably be pretty self-explanatory. P.P.S. I'd love to see localization done! :-) And it won't be as hard as it looks, because a lot of strings are reused from the Bookmarks menu.

Ahem. Either I'm crazy and didn't attach, or that attachment

Mon, 09 Apr 2007 06:01:59 +0000

Ahem. Either I'm crazy and didn't attach, or that attachment didn't make it because it was coming over a Samba share! ;)

The trean patch applied cleanly, but I can't get the xpi to

Sat, 14 Apr 2007 20:40:06 +0000

The trean patch applied cleanly, but I can't get the xpi to work properly. It installed, and i get a new "TreanMarks" menu. I also set the preferences correct, and "add bookmark" works, however, the bookmarks are never visible in the TreanMarks menu. Neither after clicking "sync now" nor after waiting for an automatic sync to happen. Mind you, this horde installation is on an SSL-enabled server, so I use https-URLs. I have not looked at the code, but from previous experiences this can lead to problems with javascript/rpc if the certificate is not accepted and such. Just a wild guess.

Hmm, sorry to hear it doesn't work. Unfortunately I won't b

Sun, 15 Apr 2007 00:01:17 +0000

Hmm, sorry to hear it doesn't work. Unfortunately I won't be able to take a closer look until next weekend. :-( I meant to test out https, but never got around to it. I think you're right that it's the cause. I'll test it out next weekend.

Moving to Feedback until Joey can update the code. Looking f

Mon, 16 Apr 2007 04:52:51 +0000

Moving to Feedback until Joey can update the code. Looking forward to checking it out then.

OK, I just tested https with both a certificate signed by an

Sun, 22 Apr 2007 00:16:27 +0000

OK, I just tested https with both a certificate signed by an Authority in Firefox (it happens to be a self-signed cert from me, which I used to sign this testing cert), and with a testing "localhost" certificate that came with Apache. The CA-signed one gave no warnings at all and I was able to browse Trean in the browser and use the TreanMarks menu. The testing cert gave two warnings: that it was not signed by a trusted authority and that the hostname didn't match. When I accepted it temporarily however, both browsing and usnig the TreanMarks menu worked. I even verified with a packet sniffer that the packets were indeed SSL. I know the error-handling of my plugin could use some improvement, so perhaps I'll do that within the next few days and you can try again. If we can't figure anything more out, perhaps some exchanging of server URLs and test accounts is in order? Thanks, Joey Hewitt > Mind you, this horde installation is on an SSL-enabled server, so I > use https-URLs. > I have not looked at the code, but from previous experiences this can > lead to problems with javascript/rpc if the certificate is not > accepted and such. > Just a wild guess.

I've been looking in to this with high hopes but unfortunate

Thu, 03 May 2007 21:25:26 +0000

I've been looking in to this with high hopes but unfortunately limited success. :) Seems like now that I have TreanMarks installed and configured, every time I launch Firefox, this shows up in my error log: Error: Warning: unrecognized command line flag -psn_0_9699329 Source File: file:///Applications/Firefox.app/Contents/MacOS/components/nsBrowserContentHandler.js Line: 655 I honestly have no clue where that's coming from, but it's definitely related. The TreanMarks menu never gets past "Loading ..." I'm attaching a 32x32 Trean icon (straight from the Tango icons). Other comments: - I'm a bit iffy on the separate menu. But if this is how other bookmarks extensions work I guess that's fine. It's certainly easier to let the main Bookmarks menu alone. - For other ways to do it than xmlrpc struts, it depends what you want to work with on the browser side. We have the beginnings of RSS/Atom feeds for Trean; if this extension could use that data that would definitely simplify things. Another possibility is to use json instead of xml-rpc; that data could be requested directly from Trean and would be much smaller than XML. And could just be eval'd (after stripping a necessary security delimiter) on the javascript side. - Can we have a configuration menu item right in the TreanMarks menu? - What do you think about calling the menu item "Horde" so that perhaps in the future it could host other Horde features? Or should we keep things separated into other extensions? Btw, I'm using FF 2.0 - not sure if versions are an issue here. I'm excited again about this - hope to get some updates from you soon. Thanks!

One other question - the extension seems to have a persisten

Thu, 03 May 2007 21:27:52 +0000

One other question - the extension seems to have a persistent cache of credentials to log in to Horde. How is this handled?

Last note for now - I committed several parts of your patch

Thu, 03 May 2007 21:50:27 +0000

Last note for now - I committed several parts of your patch that made sense independently (at least, enough sense).

> I've been looking in to this with high hopes but unfortuna

Thu, 03 May 2007 22:10:16 +0000

> I've been looking in to this with high hopes but unfortunately > limited success. :) > > Seems like now that I have TreanMarks installed and configured, every > time I launch Firefox, this shows up in my error log: > > Error: Warning: unrecognized command line flag -psn_0_9699329 > > Source File: > file:///Applications/Firefox.app/Contents/MacOS/components/nsBrowserContentHandler.js > Line: 655 I hope something didn't permanently break for you. :/ I have no idea where that came from, either. I see where it gets logged in the source, but I don't know why my extension could cause a command line flag to be passed. I'll look into it. It looks like you're using Mac. I have Windows, but it shouldn't matter with platform-independent code... > > > I honestly have no clue where that's coming from, but it's definitely > related. The TreanMarks menu never gets past "Loading ..." > > > I'm attaching a 32x32 Trean icon (straight from the Tango icons). Thanks! I'll incorporate it next time I update. > > > Other comments: > > - I'm a bit iffy on the separate menu. But if this is how other > bookmarks extensions work I guess that's fine. It's certainly easier > to let the main Bookmarks menu alone. Yes, all of the other extensions I've seen make a separate menu. (Shame that there's no simple way to make a bookmarks backend.) But I think it would be possible to add the bookmarks onto the main bookmark menu, either directly or in a submenu labeled Trean/Horde or whatever. I want to do this, but just haven't yet. > > - For other ways to do it than xmlrpc struts, it depends what you > want to work with on the browser side. We have the beginnings of > RSS/Atom feeds for Trean; if this extension could use that data that > would definitely simplify things. Another possibility is to use json > instead of xml-rpc; that data could be requested directly from Trean > and would be much smaller than XML. And could just be eval'd (after > stripping a necessary security delimiter) on the javascript side. Yeah, I thought about json afterwards. Perhaps that would be much more efficient and simple. It might also make sense to leverage the existing RSS stuff, yeah. My only problem is wondering if it makes sense to have separate download/upload mechanisms. (Though I think RSS or Atom has a publication mechanism as well, which could be used for uploading.) I should also note that the synchronization is pretty primitive right now - limited to simply the existence of bookmarks; it doesn't sync changes to URL and such. Perhaps another protocol would better address more complete synchronization. What do you think? > > - Can we have a configuration menu item right in the TreanMarks menu? I actually consciously decided against this to cut down on clutter at the top of the menu. But I think you're right that it belongs there. :-) > > - What do you think about calling the menu item "Horde" so that > perhaps in the future it could host other Horde features? Or should > we keep things separated into other extensions? Renaming it sounds fine, but I'm wondering if the menu would become too confusing if other features were integrated. > > Btw, I'm using FF 2.0 - not sure if versions are an issue here. > > I'm excited again about this - hope to get some updates from you > soon. Thanks! [paste] > One other question - the extension seems to have a persistent cache of > credentials to log in to Horde. How is this handled? It's stored in the Password Manager (Tools -> Options -> Security -> Show passwords), with a site of "treanmarksExtension." I stole the idea from another online bookmarks extension. :-) [paste] > Last note for now - I committed several parts of your patch that made sense > independently (at least, enough sense). OK. I hope they're still useful if the bookmark transfer mechanism is switched. :-) I'm fairly busy at the moment, but I'm hoping next week I can work on these things more. In the meantime, I would appreciate peoples' comments on RSS/JSON and perhaps the UI issues.

> Neither after clicking "sync now" nor after waiting for an

Sat, 12 May 2007 09:14:43 +0000

> Neither after clicking "sync now" nor after waiting for an automatic > sync to happen. I tried it unsuccessfully on Linux FF 2.0.0.3. But sync now don't even prompt for the username/password for the RPC calls.

>> - For other ways to do it than xmlrpc struts, it depends

Tue, 15 May 2007 03:42:14 +0000

>> - For other ways to do it than xmlrpc struts, it depends what you >> want to work with on the browser side. We have the beginnings of >> RSS/Atom feeds for Trean; if this extension could use that data that >> would definitely simplify things. Another possibility is to use json >> instead of xml-rpc; that data could be requested directly from Trean >> and would be much smaller than XML. And could just be eval'd (after >> stripping a necessary security delimiter) on the javascript side. > > Yeah, I thought about json afterwards. Perhaps that would be much > more efficient and simple. It might also make sense to leverage the > existing RSS stuff, yeah. My only problem is wondering if it makes > sense to have separate download/upload mechanisms. (Though I think > RSS or Atom has a publication mechanism as well, which could be used > for uploading.) Yes, Atom has a publication mechanism - we'd need to implement it, but that'd be nice anyway. :) I think JSON is probably the way to go for now for simplicity on both the Trean and Mozilla sides, but that if Atom is easy to deal with on the Mozilla side we could move to that easily, and perhaps sooner rather than later. > I should also note that the synchronization is > pretty primitive right now - limited to simply the existence of > bookmarks; it doesn't sync changes to URL and such. Perhaps another > protocol would better address more complete synchronization. What do > you think? Synchronization protocols are a tricky problem. We support SyncML in other parts of Horde, and that'd be very complete, but we'd need a full SyncML client in Mozilla, and that'd be a ton of work. I think a relatively primitive mechanism is fine for now - especially if creating/editing bookmarks are delegated to Trean. >> - What do you think about calling the menu item "Horde" so that >> perhaps in the future it could host other Horde features? Or should >> we keep things separated into other extensions? > > Renaming it sounds fine, but I'm wondering if the menu would become > too confusing if other features were integrated. You're probably right. >> One other question - the extension seems to have a persistent cache of >> credentials to log in to Horde. How is this handled? > > It's stored in the Password Manager (Tools -> Options -> Security -> > Show passwords), with a site of "treanmarksExtension." I stole the > idea from another online bookmarks extension. :-) Ah, nice. >> Last note for now - I committed several parts of your patch that made sense >> independently (at least, enough sense). > > OK. I hope they're still useful if the bookmark transfer mechanism > is switched. :-) Should be, they were related to the popup windows and such. > I'm fairly busy at the moment, but I'm hoping next week I can work on > these things more. In the meantime, I would appreciate peoples' > comments on RSS/JSON and perhaps the UI issues. Cool, looking forward to it.

OK, I finally got some time to play. I reproduced and fix

Fri, 25 May 2007 01:56:44 +0000

OK, I finally got some time to play. I reproduced and fixed a Linux problem. (Technically, it was on Iceweasel, which is the GPL'ified version of Firefox.) It was causing the TreanMarks menu to have only the fixed items (none of the bookmarks.) I'm not sure if it was what others were seeing though. I also switched to JSON. I basically just made an interface to the RPC calls I already wrote. The change wasn't quite as "drop-in" simple as I would have liked, but I've gotten rid of another layer of translation that used to be there for XML-RPC. I'm kind of hoping :-) that the MacOS bug was caused by using XML-RPC, which was implemented by a built-in Firefox XPCOM component. Perhaps it was a little different than Windows on the COM side... I'm still not sure whether JSON is the best way to go, but I'm happy for the moment because it cleaned up the code and may be more efficient. At the moment slightly more bytes go over the wires because XML-RPC was gzip-compressed, but I don't know how to do that for my JSON code. Anyone know how to do it? I'd also appreciate some assurance that I got JSON security right. I understand a comment or "while(1);" at the beginning is enough to stop people from being able to XSS your data. A few minor tweaks have been done, like adding the configuration menu item. Enjoy. Hopefully I can get to implementing some of the features I've planned, while you're testing this. I'm attaching a new XPI and a json.php file to drop into horde/trean/ It requires my previous patch.

And here's the XPI.

Fri, 25 May 2007 01:58:24 +0000

And here's the XPI.

Several thoughts: > I also switched to JSON. I basically

Fri, 25 May 2007 14:24:16 +0000

Several thoughts: > I also switched to JSON. I basically just made an interface to the > RPC calls I already wrote. The change wasn't quite as "drop-in" > simple as I would have liked, but I've gotten rid of another layer of > translation that used to be there for XML-RPC. I'm kind of hoping > :-) that the MacOS bug was caused by using XML-RPC, which was > implemented by a built-in Firefox XPCOM component. Perhaps it was a > little different than Windows on the COM side... If you still rely on the external API methods defined for Trean instead of calling the Trean API directly in json.php, would it make more sense to add a generic JSON backend to Horde's RPC library? > I'm still not sure whether JSON is the best way to go, but I'm happy > for the moment because it cleaned up the code and may be more > efficient. At the moment slightly more bytes go over the wires > because XML-RPC was gzip-compressed, but I don't know how to do that > for my JSON code. Anyone know how to do it? It's only an issue for reading the bookmarks, right? A Horde::compressOutput() in json.php should probably do that trick then. > I'd also appreciate some assurance that I got JSON security right. I > understand a comment or "while(1);" at the beginning is enough to > stop people from being able to XSS your data. Should be. Regarding the AJAX and JSON stuff inside the XPI, I suggest that you use prototype that we use anywhere else in Horde. The most recent version has support for a CSRF protection built in. Heck, we could even build the XPI on the fly including the source files directly. Much easier than rebuilding the XPI anytime you change something. I plan to do this for IMP since ages.

> Several thoughts: > >> I also switched to JSON. I basic

Fri, 25 May 2007 21:08:32 +0000

> Several thoughts: > >> I also switched to JSON. I basically just made an interface to the >> RPC calls I already wrote. The change wasn't quite as "drop-in" >> simple as I would have liked, but I've gotten rid of another layer of >> translation that used to be there for XML-RPC. I'm kind of hoping >> :-) that the MacOS bug was caused by using XML-RPC, which was >> implemented by a built-in Firefox XPCOM component. Perhaps it was a >> little different than Windows on the COM side... > > If you still rely on the external API methods defined for Trean > instead of calling the Trean API directly in json.php, would it make > more sense to add a generic JSON backend to Horde's RPC library? It would. I had a reason for deciding against implementing JSON-RPC (pretty much the only RPC-over-JSON standard I saw.) (http://json-rpc.org/wiki/specification) Now I'm not sure why, but I think it may be that the newest version is still being written up in specification. I'll look at it some more. > >> I'm still not sure whether JSON is the best way to go, but I'm happy >> for the moment because it cleaned up the code and may be more >> efficient. At the moment slightly more bytes go over the wires >> because XML-RPC was gzip-compressed, but I don't know how to do that >> for my JSON code. Anyone know how to do it? > > It's only an issue for reading the bookmarks, right? A > Horde::compressOutput() in json.php should probably do that trick > then. Thanks, I'll try that. > >> I'd also appreciate some assurance that I got JSON security right. I >> understand a comment or "while(1);" at the beginning is enough to >> stop people from being able to XSS your data. > > Should be. > > Regarding the AJAX and JSON stuff inside the XPI, I suggest that you > use prototype that we use anywhere else in Horde. The most recent > version has support for a CSRF protection built in. > Heck, we could even build the XPI on the fly including the source > files directly. Much easier than rebuilding the XPI anytime you > change something. I plan to do this for IMP since ages. This sounds like a good idea to look into. Where is the source? Thanks, Joey P.S. Today was my last day of high school, woohoo! And I'll even have a week that will be pretty open for working on this ;)

>> If you still rely on the external API methods defined for

Fri, 25 May 2007 21:52:57 +0000

>> If you still rely on the external API methods defined for Trean >> instead of calling the Trean API directly in json.php, would it make >> more sense to add a generic JSON backend to Horde's RPC library? > > It would. I had a reason for deciding against implementing JSON-RPC > (pretty much the only RPC-over-JSON standard I saw.) > (http://json-rpc.org/wiki/specification) Now I'm not sure why, but I > think it may be that the newest version is still being written up in > specification. I'll look at it some more. The spec looks good. >> Regarding the AJAX and JSON stuff inside the XPI, I suggest that you >> use prototype that we use anywhere else in Horde. The most recent >> version has support for a CSRF protection built in. >> Heck, we could even build the XPI on the fly including the source >> files directly. Much easier than rebuilding the XPI anytime you >> change something. I plan to do this for IMP since ages. > > This sounds like a good idea to look into. Where is the source? In my head. But it shouldn't be too hard. We have the Horde_Compress library that we already use to create ZIP files on the fly. We should probably put the XPI contents under trean/lib/XPI or trean/templates/xpi with the same layout like in the XPI file, for better maintainability. > P.S. Today was my last day of high school, woohoo! And I'll even > have a week that will be pretty open for working on this ;) Congrats! Good for us, I guess.

>> It would. I had a reason for deciding against implementi

Sat, 26 May 2007 00:23:31 +0000

>> It would. I had a reason for deciding against implementing JSON-RPC >> (pretty much the only RPC-over-JSON standard I saw.) >> (http://json-rpc.org/wiki/specification) Now I'm not sure why, but I >> think it may be that the newest version is still being written up in >> specification. I'll look at it some more. > > The spec looks good. Yeah, on second glance it's alright. I think I've finished implementing the backend, but I haven't tested with a real JSON-RPC client yet. I'll probably adapt an existing JSON-RPC library to use Horde's AJAX/JSON stuff, and use that for my extension. As for security, I think the point is moot, now that the only way anything useful can be retrieved is with a POST, and nobody should be able to forge and read with POST, right? > >>> Regarding the AJAX and JSON stuff inside the XPI, I suggest that you >>> use prototype that we use anywhere else in Horde. The most recent >>> version has support for a CSRF protection built in. >>> Heck, we could even build the XPI on the fly including the source >>> files directly. Much easier than rebuilding the XPI anytime you >>> change something. I plan to do this for IMP since ages. >> >> This sounds like a good idea to look into. Where is the source? > > In my head. But it shouldn't be too hard. We have the Horde_Compress > library that we already use to create ZIP files on the fly. We should > probably put the XPI contents under trean/lib/XPI or > trean/templates/xpi with the same layout like in the XPI file, for > better maintainability. Well, actually, I don't have to re-compress for my own development because there's a way to point Firefox at a directory and it works just like an XPI had been installed there. But if I understand what you're saying, it would be neat. The XPI could be downloaded from the Horde server, which would allow us to throw in some subtle features like making the XPI's default server URL be the server you're downloading from. (Perhaps that would not be desirable, though.) Is that what you meant?

> As for security, I think the point is moot, now that the o

Sat, 26 May 2007 10:25:27 +0000

> As for security, I think the point is moot, now that the only way > anything useful can be retrieved is with a POST, and nobody should be > able to forge and read with POST, right? No, POSTs can be forged as well. > just like an XPI had been installed there. But if I understand what > you're saying, it would be neat. The XPI could be downloaded from > the Horde server, which would allow us to throw in some subtle > features like making the XPI's default server URL be the server > you're downloading from. (Perhaps that would not be desirable, > though.) Is that what you meant? Exactly. And I actually started working on this yesterday, maybe I can show something in the next few days.

>> As for security, I think the point is moot, now that the

Sat, 26 May 2007 17:18:41 +0000

>> As for security, I think the point is moot, now that the only way >> anything useful can be retrieved is with a POST, and nobody should be >> able to forge and read with POST, right? > > No, POSTs can be forged as well. OK, can you think of a way I can transparently implement security? I only know of putting something at the beginning of the JSON, so that we can strip it off but nobody else can because they can't read it directly. Unfortunately, I'm guessing this will break the JSON-RPC spec. > >> just like an XPI had been installed there. But if I understand what >> you're saying, it would be neat. The XPI could be downloaded from >> the Horde server, which would allow us to throw in some subtle >> features like making the XPI's default server URL be the server >> you're downloading from. (Perhaps that would not be desirable, >> though.) Is that what you meant? > > Exactly. And I actually started working on this yesterday, maybe I > can show something in the next few days. OK, thanks!

I still can't get this to work - now I have even disabled ht

Sun, 27 May 2007 14:31:42 +0000

I still can't get this to work - now I have even disabled https, to be able to debug a bit more. There seems to be a problem with the request TreanMarks is sending, that json.php does not understand: GET /trean/json.php??method=syncBookmarks¶ms=%5B1%2C%5B%5D%5D This results in an (...) Content-Type: text/javascript while(1);/*Not found.*/false The "params" unescaped seems to be "[1,[]]" - not sure what they should be or if this is in fact correct but something in my horde installation is missing.

I'm attaching an XPI that should fix this. Thanks a lot for

Sun, 27 May 2007 19:30:45 +0000

I'm attaching an XPI that should fix this. Thanks a lot for the detailed report! - I might not have figured it out otherwise. Read on for technical details and request for comments. Hardcoding is a bad idea! I've had an assumption in my code for ages, and I forgot about it. For simplicity, I hacked in that the root folder would always have ID 1. This works great for testing, but if you have more than one Trean user on the server, I guess it's likely to break. I think this is what has been happening to you. I'm attaching a new XPI with this assumption removed from my code. It changes the way the menu appears. I see now only one folder at the top level, with "joey's Bookmarks." (I believe this is called a share.) Everything that used to appear at the top level is under that. I don't have time today, but within this week I'd like to work on more advanced caching and prefetching, during the course of which I'd like to offer the ability to remove this extra top-level. It looks like other users can share their bookmarks with you, so it may be useful to let the user pick which "share" to make the top-level. Other users' bookmarks would then appear as a "John's Bookmarks" folder. Anyone have more suggestions on how to handle the top-level folders (or shares)? I hope this works for you; it's a shame something so silly on my part has been holding you up from trying it out. :-) > I still can't get this to work - now I have even disabled https, to > be able to debug a bit more. > There seems to be a problem with the request TreanMarks is sending, > that json.php does not understand: > > GET /trean/json.php??method=syncBookmarks¶ms=%5B1%2C%5B%5D%5D > > This results in an > (...) > Content-Type: text/javascript > while(1);/*Not found.*/false > > The "params" unescaped seems to be "[1,[]]" - not sure what they > should be or if this is in fact correct but something in my horde > installation is missing. > >

I must not have privileges to remove treanmarks2.xpi. Will

Sun, 27 May 2007 19:33:10 +0000

I must not have privileges to remove treanmarks2.xpi. Will someone do so? I will upload as treanmarks.xpi from now on. Thanks, Joey

Perfect! Now it works as it should, I believe. Even with

Sun, 27 May 2007 19:36:59 +0000

Perfect! Now it works as it should, I believe. Even with https. Thanks a lot for your work!

One issue, tough I am not sure it belongs in this Bug# I

Sun, 27 May 2007 19:44:28 +0000

One issue, tough I am not sure it belongs in this Bug# I have a lot of "QuickSearches" - IE http://www.php.net/manual-lookup.php?pattern=%s and such (mapped to the keyword "php" so i type "php string" in the address bar and is directly taken to "http://www.php.net/manual-lookup.php?pattern=string"). Would it be possible to add this to the extension, or should I keep that as a separate issue?

> One issue, tough I am not sure it belongs in this Bug# >

Sun, 27 May 2007 23:46:22 +0000

> One issue, tough I am not sure it belongs in this Bug# > > I have a lot of "QuickSearches" - IE > http://www.php.net/manual-lookup.php?pattern=%s and such (mapped to > the keyword "php" so i type "php string" in the address bar and is > directly taken to > "http://www.php.net/manual-lookup.php?pattern=string"). > > Would it be possible to add this to the extension, or should I keep > that as a separate issue? That sounds useful, but what does it have to do with Trean or Horde?

It does work with the normal bookmarks. My question was mai

Mon, 28 May 2007 07:44:24 +0000

It does work with the normal bookmarks. My question was mainly if it was possible to add this kind of functionality to an extension such as this. If so, I can throw away all the local bookmarks in the browser, and only use Trean and TreanMarks.

> OK, can you think of a way I can transparently implement s

Mon, 28 May 2007 08:11:34 +0000

> OK, can you think of a way I can transparently implement security? I > only know of putting something at the beginning of the JSON, so that > we can strip it off but nobody else can because they can't read it > directly. Unfortunately, I'm guessing this will break the JSON-RPC > spec. It might break the specs indeed, but take a look at how it is implemented with IMP/prototype. In imp/lib/IMP.php, IMP::sendHTTPResponse(), the json code is encapsulated in "/*-secure- */". prototype (horde/js/src/prototype.js) automatically filters the comments out, see Prototype.JSONFilter and String.unfilterJSON().

Alright, so I basically knew what to expect, but damn that's

Wed, 20 Jun 2007 03:10:06 +0000

Alright, so I basically knew what to expect, but damn that's cool. I've committed the patches and the XPI works for me with FF2 (tested in Parallels on windows). Minor stuff: - Do we need to have the popup stuff in Trean for this? I don't see obvious places where the extension uses it (might be because I was already logged in to Horde when I clicked "Organize"? But I think it's fine to have a full Horde UI for that) - The configure dialog could use a little text wrapping - I take it this doesn't work with FF 1.5? I got a very odd result trying it with 1.5. Not a huge deal, just curious if it's known. - What would you think about naming it "Trean Places" instead of "TreanMarks"? This occurs to me since the bookmarks feature is being renamed "places" in FF3. - The extension icon looks pretty, huh? ;) Finally, most important: where/how do we want to host and distribute the XPI? I assume that we should have the uncompressed files checked in to CVS as a TreanPlaces project or something (maybe we should have a BrowserPlugins module to hold other stuff, too?); then I guess it'd be great to put it up on the moz plugins site if we can get it approved. Other thoughts here? Jan, any progress serving the XPI out of Horde? I'm installing this at work tomorrow. Very sweet. Thanks!

> Finally, most important: where/how do we want to host and

Wed, 20 Jun 2007 07:40:01 +0000

> Finally, most important: where/how do we want to host and distribute > the XPI? I assume that we should have the uncompressed files checked > in to CVS as a TreanPlaces project or something (maybe we should have > a BrowserPlugins module to hold other stuff, too?); then I guess it'd > be great to put it up on the moz plugins site if we can get it > approved. Other thoughts here? Jan, any progress serving the XPI out > of Horde? Yes, but I started cleaning up the whole extension which is obviously more work than just getting the XPI working. But the layout I use is the following: imp/extension.php is providing the XPI and the XPI is built from files in imp/templates/extension/. The layout in this directory is the same like in the XPI to ease maintenance. But it doesn't have to. I attach an extensions.php the simply takes the directory one-to-one, in real life we need some processing, i.e. adding the correct URLs, etc. This is why I don't agree with your approach of having the extension(s) in a separate module or even on the mozilla site. The idea is to have one extension per (Horde) site. 1) because users don't have to configure any site settings like URLs etc., 2) users can have separate extensions for each Horde site, and 3) users can get extension updates automatically from the Horde sites, depending on the IMP/Trean version they run. With "Horde sites" I obviously don't mean horde.org, but sites that have Horde installed.

> Yes, but I started cleaning up the whole extension which i

Wed, 20 Jun 2007 07:55:05 +0000

> Yes, but I started cleaning up the whole extension which is obviously > more work than just getting the XPI working. OK, before you do anything drastic there - I've been playing with a new design. Yes, I keep rewriting lots of things, but I guess that's what happens to hobbyists. I've enjoyed learning everything I have, anyways. ;-) I originally wanted to extend the browser's bookmarks datasource to aggregate in the Trean bookmarks. I gave up on that pretty quickly because it seemed too complex. Then lately I was polishing the extension, and I got tired of all the functionality (especially user-interface) I was duplicating. I've gotten through some initial learning-curve problems I had with the datasource before, so now I'm experimenting with it. If I do it right, I can transparently and automatically get all the functionality normal bookmarks have. This would be very elegant, powerful, and ultimately easy (I hope!) And unless Mozilla makes any big changes in future versions, it would "fit" better (UI-wise) and be more likely to work without changes, in newer versions of the browser. > > But the layout I use is the following: imp/extension.php is providing > the XPI and the XPI is built from files in imp/templates/extension/. > The layout in this directory is the same like in the XPI to ease > maintenance. But it doesn't have to. I attach an extensions.php the > simply takes the directory one-to-one, in real life we need some > processing, i.e. adding the correct URLs, etc. extension.php looks nice. It will be cool to see Trean serve up its own extension. > > This is why I don't agree with your approach of having the > extension(s) in a separate module or even on the mozilla site. The > idea is to have one extension per (Horde) site. 1) because users > don't have to configure any site settings like URLs etc., 2) users > can have separate extensions for each Horde site, and 3) users can > get extension updates automatically from the Horde sites, depending > on the IMP/Trean version they run. With "Horde sites" I obviously > don't mean horde.org, but sites that have Horde installed. These are good ideas!

>> Yes, but I started cleaning up the whole extension which

Wed, 20 Jun 2007 08:26:43 +0000

>> Yes, but I started cleaning up the whole extension which is obviously >> more work than just getting the XPI working. > > OK, before you do anything drastic there - I've been playing with a > new design. Yes, I keep rewriting lots of things, but I guess that's > what happens to hobbyists. No worries, I was talking about the IMP extension I'm working on. ;-)

Any plans to have multiply server support?

Wed, 20 Jun 2007 13:36:37 +0000

Any plans to have multiply server support?

That's what I was talking about. One extension per server.

Wed, 20 Jun 2007 14:38:47 +0000

That's what I was talking about. One extension per server.

> That's what I was talking about. One extension per server.

Wed, 20 Jun 2007 15:49:35 +0000

> That's what I was talking about. One extension per server. How does that work when the extension provides a menu? Seems unwieldy to me, and likely to cause internal conflicts...

>> That's what I was talking about. One extension per server

Wed, 20 Jun 2007 16:02:41 +0000

>> That's what I was talking about. One extension per server. > > How does that work when the extension provides a menu? Providing a named menu, just like we would provide named extensions. > Seems unwieldy to me, and likely to cause internal conflicts... But it's the only way I can imagine to have configuration-less extensions, instead of having the users to enter urls and stuff. And it makes sure that the extension running is compatible with the installed Horde version, think a few releases ahead.

A few notes on the XPI after using it a little: - right n

Thu, 21 Jun 2007 03:19:15 +0000

A few notes on the XPI after using it a little: - right now Trean only allows one share per user, so it'd be nice to skip the top level (i.e. "Chuck Hagenbuch's Bookmarks") and have the next level right in the top level menu. Once we allow more shares, maybe we can still do this, but with the share name as "labels" of menu sections. - the configuration dialog doesn't have an OK button (in FF2/MacOS). Hitting escape seems to save things okay though. - Also FF2/Mac, when I navigate to a category in the menu, I see Loading ... It doesn't change from that to the actual list, though, until I move away from the category and then back to it.

Is anyone else seeing that firebug breaks when this extensio

Thu, 21 Jun 2007 04:13:45 +0000

Is anyone else seeing that firebug breaks when this extension is enabled?

> Is anyone else seeing that firebug breaks when this extens

Thu, 21 Jun 2007 13:42:10 +0000

> Is anyone else seeing that firebug breaks when this extension is enabled? Yes firebug breaks for me as well

I can confirm that as well, along with some other xhr stuff.

Fri, 22 Jun 2007 04:07:03 +0000

I can confirm that as well, along with some other xhr stuff.

I've also noticed the Firebug errors (and possibly general X

Fri, 06 Jul 2007 14:39:57 +0000

I've also noticed the Firebug errors (and possibly general XHR problems, too, I can't remember.) Are these problems really interfering with anything important, or are they just errors in the console? I'll take some time to fix them if so; otherwise, I'll just continue working on the new datasource design. Speaking of it, it's coming along pretty well. I've got read-only, non-syncing support working right now. It's neat because right away I got some new features, like the "Open in All Tabs" item at the bottom of folders menus (I hadn't noticed it, or I would have implemented it before) Also, the Trean Bookmarks are available directly within the Bookmarks menu right now, and are visible in the Bookmarks Manager (Organize Bookmarks), complete with standard working properties dialog. Hopefully I can get a release out soon!

> I've also noticed the Firebug errors (and possibly general

Fri, 06 Jul 2007 21:07:11 +0000

> I've also noticed the Firebug errors (and possibly general XHR > problems, too, I can't remember.) Are these problems really > interfering with anything important, or are they just errors in the > console? I'll take some time to fix them if so; otherwise, I'll just > continue working on the new datasource design. They mean that I can't use the extension, unfortunately, because I use firebug for work pretty regularly, and with xhr broken some of my current work project doesn't work at all. But I can wait for the new datasource stuff, so it's up to you to decide which to work on first. :) > Speaking of it, it's coming along pretty well. I've got read-only, > non-syncing support working right now. It's neat because right away > I got some new features, like the "Open in All Tabs" item at the > bottom of folders menus (I hadn't noticed it, or I would have > implemented it before) Also, the Trean Bookmarks are available > directly within the Bookmarks menu right now, and are visible in the > Bookmarks Manager (Organize Bookmarks), complete with standard > working properties dialog. Hopefully I can get a release out soon! Sounds great!

OK, here's the latest! It's hard to think of all that's cha

Wed, 25 Jul 2007 21:39:08 +0000

OK, here's the latest! It's hard to think of all that's changed since last version, since it's a different design. But, I've got complete integration into the browser, including: adding/removing bookmarks, organizing them (even custom sorting, though that can't be saved to the server), moving them between your local bookmarks and Trean, searching them in the Bookmarks Manager. Syncing should be working both ways now. Bookmarks are saved so that the next time you open the browser, it will sync rather than re-download. (Also you should be able to view them offline.) On the downsides, error-reporting is minimal for the moment. I think the RPC APIs are a bit messy and might need re-thinking. The options to swap bookmark-making command keys, and to put Trean bookmarks and local Bookmarks in separate menus are not implemented right now. As to horde (at) olen (dot) net's question about the special search keyword bookmarks, I think this can be done. It would need a bit of hackiness to store in Trean properly, but I think it could be as simple as a special "keyword=string" pattern in the Trean description or something. I'll look closer soon. Hopefully I'm attaching all the changes necessary on the server-side...

Here's some instructions on how to set this up. You need th

Wed, 25 Jul 2007 21:58:09 +0000

Here's some instructions on how to set this up. You need these files: treanmarks[1].xpi server_changes.zip Get server_changes.zip, extract it, and follow the instructions in changes.txt to place the 3 PHP files inside where they need to be. (You'll be overwriting existing Horde files in 2 cases, so I'd suggest making backups of them.) Install the XPI on Firefox. Open Tools -> Add-ons and point the extension to your Horde base URL (i.e. http://www.example.com/horde) I highly recommend making backups of both your Trean bookmarks and your local Firefox bookmarks! Firefox bookmarks are found in your profile directory, with the name bookmarks.html Again, I'm hoping I remembered all changes necessary. Please make a comment if you're having problems! -Joey P.S. Will someone with perms delete these attachments, so it's not so cluttered: treanmarks.xpi treanmarks.diff emblem-favorite.png json.php

> P.S. Will someone with perms delete these attachments, so

Wed, 25 Jul 2007 22:00:53 +0000

> P.S. Will someone with perms delete these attachments, so it's not so cluttered: Done. I'm hoping to have a look at the changes over the next few evenings. Thanks!

OK, here's a diff against CVS HEAD from last night. Note

Fri, 27 Jul 2007 16:54:07 +0000

OK, here's a diff against CVS HEAD from last night. Note that you'll have to ensure that the new horde/framework/RPC/RPC/jsonrpc.php file ends up in your PHP include path. Hopefully this is much easier for people to review. I'm not in a hurry to see it committed to CVS, but if it's easier for someone to do it now, I guess I'm alright with the new JSON-RPC stuff (small change to horde/rpc.php, a new jsonrpc.php file mentioned above, and removal of obsoleted trean/json.php) being committed. But trean/lib/api.php needs some documentation, if not reworking, before I'm finished with it. If I decide I no longer need some API methods, do we think anyone is using them right now? Here are some things I have in mind for more work on the extension: o More error checking and reporting o Finish implementation of separate TreanMarks/Bookmarks menus o Downloading the XPI from the Horde server o Setup wizard, a la Foxmarks, with configuration of Horde server URL (with nice preset URL set to the server it was downloaded from, perhaps other settings pulled from server too), import of Firefox bookmarks. o Multiple Horde servers/users aggregated into the bookmarks o Start investigating Firefox 3, as I have a nasty feeling its "Places" replacement for bookmarks is a new implementation that could be drastically different :-) Any other suggestions? -Joey P.S. I haven't seen any XHR/Firebug errors with this rewrite, so I think that's fixed!

Just to give an update, I'm still hoping to look at this soo

Sun, 12 Aug 2007 18:25:22 +0000

Just to give an update, I'm still hoping to look at this soon, but I had a hard drive fail and an otherwise miserable week, so I'm going to need to rebuild my laptop first before I can look at this. Hopefully someone else can take a peek though, too.

Taking a look at this in between semi-productive late night

Wed, 15 Aug 2007 04:59:43 +0000

Taking a look at this in between semi-productive late night work. Do I understand correctly that the server_changes.zip file can be discarded, and that treanmarks.diff replaces it completely? Seems to be slow, so far, but nothing definitive - I was eventually prompted for password; no bookmarks showing up yet. The Trean Bookmarks folder only shows up in windows opened after a certain point - not sure exactly what that point was. Could really use some status indicators so I know whether it's given up or if it's working. :)

> Taking a look at this in between semi-productive late nigh

Wed, 15 Aug 2007 05:42:14 +0000

> Taking a look at this in between semi-productive late night work. Do > I understand correctly that the server_changes.zip file can be > discarded, and that treanmarks.diff replaces it completely? Correct. > > Seems to be slow, so far, but nothing definitive - I was eventually > prompted for password; no bookmarks showing up yet. The Trean > Bookmarks folder only shows up in windows opened after a certain > point - not sure exactly what that point was. Hmm, I don't think I've tested without a cached password recently. Perhaps there is a bug. There could also be a problem if you didn't apply my server changes correctly. I might make some changes when I look into the problem with multiple windows; there could very well be some issues, but I don't think they're major. > > Could really use some status indicators so I know whether it's given > up or if it's working. :) I'll think about how to do this best. My test server is on my LAN, which means I'm oblivious to the more noticeable delays everyone else has. Thanks for the feedback, however preliminary!

>> Taking a look at this in between semi-productive late nig

Thu, 16 Aug 2007 16:01:49 +0000

>> Taking a look at this in between semi-productive late night work. Do >> I understand correctly that the server_changes.zip file can be >> discarded, and that treanmarks.diff replaces it completely? > > Correct. Okay, keeping the ticket clean. :) Thanks. > Hmm, I don't think I've tested without a cached password recently. > Perhaps there is a bug. There could also be a problem if you didn't > apply my server changes correctly. Any suggestions on how best to check this? I could commit what I have so you can check it out; that might be best. >> Could really use some status indicators so I know whether it's given >> up or if it's working. :) > > I'll think about how to do this best. My test server is on my LAN, > which means I'm oblivious to the more noticeable delays everyone else > has. I was testing at home on my LAN also. Didn't seem to load anything. I'll try again today from another computer. > Thanks for the feedback, however preliminary! Also in the way of preliminary feedback, with TreanMarks enabled I seemed to have some trouble with regular bookmark management - when I created a new (local) bookmark folder, it was impossible to rename it from "New Folder" to the name I wanted - I could go into the properties dialog, but my changes were ignored. Or was it trying to sync that folder to Trean, and failing because of the other failures?

I think it must be a cached password problem - I just tried

Thu, 16 Aug 2007 16:16:42 +0000

I think it must be a cached password problem - I just tried on a computer where I had had a previous TreanMarks version installed (and thus had the password cached) and it is working almost perfectly. The only other problem I see so far is that there are a few of my Trean folders which show up in Firefox as empty. Any suggestions on how to trace where the problem is there? Thanks!

I've committed the Trean part of the changes. I hesitate the

Thu, 16 Aug 2007 16:29:55 +0000

I've committed the Trean part of the changes. I hesitate the commit the jsonrpc implementation, though, because of security concerns. I don't know if there is going to be an easy way to fix this, but I don't think we can roll it out if it's possible to exploit. Here's the concern: if a user is using TreanMarks and is authenticated, another website with malicious javascript code could use XmlHttpRequest to POST jsonrpc requests to Horde without the user knowing. This actually goes beyond Trean since the user's authentication to Horde would be used; any API method would be callable. My first thought of how to handle this is that instead of using HTTP basic authentication, we need to have the jsonrpc backend use a real session, with a session key stored in the extension and included in requests as a POST parameter (like the Horde_Form token usage for CSRF protection) for checking. Thoughts?

Thanks for your feedback, and for pointing this out! > I'

Thu, 16 Aug 2007 16:59:46 +0000

Thanks for your feedback, and for pointing this out! > I've committed the Trean part of the changes. I hesitate the commit > the jsonrpc implementation, though, because of security concerns. I > don't know if there is going to be an easy way to fix this, but I > don't think we can roll it out if it's possible to exploit. > > Here's the concern: if a user is using TreanMarks and is > authenticated, another website with malicious javascript code could > use XmlHttpRequest to POST jsonrpc requests to Horde without the user > knowing. This actually goes beyond Trean since the user's > authentication to Horde would be used; any API method would be > callable. I'm sure you know more about this than I do. But I'm not sure how it's exploitable. How is the extension being "logged in" any different from the user being logged in to Horde? Doesn't cross-domain security already prevent a malicious site from doing this, whether the user himself is logged in or the extension is? I suppose code not subject to XHR security checks (another extension) could make a POST, but such code has so much control already that it seems futile to try to protect against it. Regardless, you bring up some very good points. We'll want to think it through several times. > > My first thought of how to handle this is that instead of using HTTP > basic authentication, we need to have the jsonrpc backend use a real > session, with a session key stored in the extension and included in > requests as a POST parameter (like the Horde_Form token usage for > CSRF protection) for checking. I'll need to learn how this is done, but I'm sure it wouldn't be too hard to implement. Thanks again.

I remembered that the browser is caching the HTTP Basic cred

Thu, 16 Aug 2007 17:32:15 +0000

I remembered that the browser is caching the HTTP Basic credentials, which is bad. I think I can prevent that. I'm hoping after the first call using Basic auth, the cookie I get will be enough. But I think I see now how it's exploitable. Couldn't someone automatically submit a FORM with a POST to Horde, and the auth cookie would attach to the request regardless of the domain of the POSTing site? I guess they may not be able to do much with the response, but just sending is enough to do nasty things. So you're suggesting my extension holds a unique, opaque session key (probably in addition to the cookie I already have) that isn't stored anywhere in the browser proper? Also, is this really specific to JSON-RPC, or is it something that could be a problem with any of the RPC methods? Because on second thought, I think JSON-RPC requests would be difficult to forge because XHR is probably protected enough, and they can't be done by FORM that I know of, because they aren't sent using the standard URL encoding form. They use a POST Content-Type of 'application/json' or something, and the body is straight JSON, not wrapped in URL &key=value form. I hope it makes sense what I'm getting at here!

> I remembered that the browser is caching the HTTP Basic cr

Thu, 16 Aug 2007 20:05:57 +0000

> I remembered that the browser is caching the HTTP Basic credentials, > which is bad. I think I can prevent that. I'm hoping after the > first call using Basic auth, the cookie I get will be enough. Unless we modify jsonrpc to use sessions instead of HTTP auth, that won't work. > But I think I see now how it's exploitable. Couldn't someone > automatically submit a FORM with a POST to Horde, and the auth cookie > would attach to the request regardless of the domain of the POSTing > site? I guess they may not be able to do much with the response, but > just sending is enough to do nasty things. Right. This is a pretty good explanation: http://en.wikipedia.org/wiki/Cross-site_request_forgery > So you're suggesting my extension holds a unique, opaque session key > (probably in addition to the cookie I already have) that isn't stored > anywhere in the browser proper? As long as it's not something that is passed when the browser makes a regular page request, or an xhr request, it'll work. > Also, is this really specific to JSON-RPC, or is it something that > could be a problem with any of the RPC methods? Because on second > thought, I think JSON-RPC requests would be difficult to forge > because XHR is probably protected enough, and they can't be done by > FORM that I know of, because they aren't sent using the standard URL > encoding form. They use a POST Content-Type of 'application/json' or > something, and the body is straight JSON, not wrapped in URL > &key=value form. XHR is protected by cross-domain restrictions; you can do GET requests for javascript, but jsonrpc (and the other RPC stuff) uses POST. Other RPC types could be vulnerable if they could be faked by a form submission. I think you're right that a regular form submit couldn't be used for jsonrpc (or most of the other RPC types) because you can't create that data with a regular form. Since the only other way to get the user's browser to do a POST is with XHR, and that's out of domain, then I think we're okay here without additional changes and tokens. But it's a good thing to think through. :) I want to sit on this another day or so before committing it, though, just in case. Thanks!

> Seems to be slow, so far, but nothing definitive - I was e

Sat, 18 Aug 2007 23:52:39 +0000

> Seems to be slow, so far, but nothing definitive - I was eventually > prompted for password; no bookmarks showing up yet. The Trean > Bookmarks folder only shows up in windows opened after a certain > point - not sure exactly what that point was. I realized these sound like symptoms of some errors going on, which aren't reported right now. Hopefully I can add reporting within a few days. Your other points about status, etc., were still good, though.

The json-rpc driver is now in CVS, fyi.

Sun, 26 Aug 2007 03:33:10 +0000

The json-rpc driver is now in CVS, fyi.

Unfortunately I'm just not going to have any more time to fi

Fri, 30 Nov 2007 21:49:47 +0000

Unfortunately I'm just not going to have any more time to finish this. I won't even be around to get the bounty, so I guess if someone builds on my solution and finishes it, they can have the bounty. I hate to leave half-working code behind, but as I understand it Firefox 3 will be coming soon and is overhauling the Bookmarks code anyways. My techniques might not even work there. I assigned the copyright over to Horde, so it's all yours! Good luck with the project. -- Joey Hewitt

Sorry to hear that! Maybe you'll be able to contribute again

Fri, 30 Nov 2007 22:03:08 +0000

Sorry to hear that! Maybe you'll be able to contribute again some day...

http://developer.mozilla.org/en/docs/Places:Migration_Guide

Mon, 19 May 2008 02:22:51 +0000

http://developer.mozilla.org/en/docs/Places:Migration_Guide http://developer.mozilla.org/en/docs/Firefox_3_for_developers

probably not worth doing this for ff2 at this point...

Sun, 25 May 2008 20:53:02 +0000

probably not worth doing this for ff2 at this point...

Mozilla seems to develop a centralized Browser-Data-System f

Sat, 19 Jul 2008 10:59:47 +0000

Mozilla seems to develop a centralized Browser-Data-System for Firefox 3. It is still in alpha stdium but i use it and it works great. It syncs Bookmarks, History, Tabs, Passwords etc (configurable) on a WebDAV-server of your choice. Actual the alpha can save the stuff only encrpyted, but there seems to be a unencrypted option planned. Also a Documentation of the cryptin-API is available, so trean could adept it.... http://wiki.mozilla.org/Labs/Weave There is a ServerAPI available, but it will change often due to alpha-stadium. Actually readOnly-Querys about bokmark-data is possible. Maybe it is a good start to adapt Treans Datastructure (incl. possibility to edit) to the needs of FF3 ( does Trean contains bookmark-tagging already? ). Next steps would be the sync-algorith and the encryption... It woul be nice if i could help to develop trean... best regards, Torben Dannhauer

> Maybe it is a good start to adapt Treans Datastructure (in

Sat, 19 Jul 2008 13:18:06 +0000

> Maybe it is a good start to adapt Treans Datastructure (incl. > possibility to edit) to the needs of FF3 ( does Trean contains > bookmark-tagging already? ). http://bugs.horde.org/ticket/6868 > Next steps would be the sync-algorith and the encryption... > > It woul be nice if i could help to develop trean... Help is always welcome. Trean needs some pretty major refactoring related to the Horde_Share system to either move it to the new native hierarchical sql share driver or to flatten the data storage and maintain single level "buckets" of bookmarks that contain tagged bookmarks which can be browsed in a hierarchical fashion (similar to Ansel's tag browsing feature). This still needs to be discussed some more, but IMO, this work should be done before anything else is added to Trean. If your familiar with Horde_Share api (or want to *become* familiar with it ;) feel free to dig in, submit patches, ask questions on the mailing lists etc... I was planning on doing this work, but as always, there is never enough time for everything :)

To second Michael, you are absolutely welcome to help deve

Sun, 20 Jul 2008 04:45:57 +0000

To second Michael, you are *absolutely* welcome to help develop Trean. If you have questions on Horde stuff, please feel free to ask on the dev list (dev@lists.horde.org - http://horde.org/mail/).

Sadly, Firefox 3 is now 5 major versions back.

Sun, 13 Nov 2011 00:31:19 +0000

Sadly, Firefox 3 is now 5 major versions back.