from:"IGnatius T Foobar"

Well folks, I think I finally figured out the "disappearing netconfigs" 
issue.  
   
 It happens when you run out of disk space.  
   
 That happened to me a couple of days ago.  All gone.  :(

[Citadel Development] (no subject)

I guess you can email me the details if there's a security problem.  If 
it's really something that can't be fixed in a compatible way, then we'll 
change the command name.  Old clients will fall back to unencrypted 
connections.

[Citadel Development] (no subject)

 >OK, now that I've been out of this for so long, where are the svn repos  
 
 >at? 
   
 svn+ssh://er...@uncensored.citadel.org/appl/svn/

[Citadel Development] Re: Citadel commit log: revision 8139

 >If a message is received and the message saved to disk but TDAP runs 
before   
 >the msg pointers are saved in any room then is it possible for the 
message to   
 >be purged by TDAP? I don't fully understand how TDAP decides to delete 
the   
 >message yet. 
   
 TDAP purges a message when its reference count reaches zero.   Dig dis:  
   
 * Whenever a message is saved to a room, or removed from a room, we write 
a record to refcount_adjustments.dat indicating a +1 or -1 delta.  
   
 * TDAP purges users and rooms first, which, as always, writes more of 
those deltas  
   
 * The last thing TDAP does is to read and flush refcount_adjustments.dat 
to the database, updating the message's metadata.  It is at this time that 
we delete any messages whose reference count has reached zero.  
   
 I hope that clears things up.

[Citadel Development] Re: Patch: fix unread msgs status in webcit iconbar/tree room view

 >ok, done; I hope no more old messages make it over? ;-)   
   
 Yeah, I don't know what happened there.  
   
 Should we put this code in stable too?

[Citadel Development] Re: 7.70 release

   
 Easy Install has been updated to stable-77x.  Tarballs to follow, after 
we let a few people act as "guinea pigs" :)  
   
 I wonder if I should strip the new bbsview code out of stable-77x, since 
it's not going to get used anyway?

[Citadel Development] Re: Citadel commit log: revision 8139

2009-12-17 Thread IGnatius T Foobar

Sounds very cool, but is this going to be one of those things that only 
davew understands and therefore becomes difficult to maintain?

[Citadel Development] 7.70 release

2009-12-17 Thread IGnatius T Foobar



Yes, we should continue to make use of release branches.  I just don't want them to live *too* long.  We'll keep stable-77x around for backports of bug fixes if that's the release that makes it into Debian stable, of course.
I think what I'm trying to say here is that we should never let svn head get "very" unstable.  We did that last year and by the time we got it finished, there were so many bugs in it that we didn't catch in our own testing, that it became quite a setback to get it stable again.

[Citadel Development] 7.70 release

2009-12-16 Thread IGnatius T Foobar



Uncensored is now running on the stable-77x branch.  Assuming everything still looks good tomorrow morning, I will push this branch out to Easy Install and build some tarballs too.
I don't want this to be a long-lived branch for anything other than Debian stable.  The last time we lived too long with an unstable head, we had all sorts of poorly tested code still in place when head became the new stable.
I'll be working on the new bbs view.   Is the vCard edit bug definitely fixed now?

[Citadel Development] (no subject)

2009-12-11 Thread IGnatius T Foobar

 >the one with the admin editing a users vcard, and getting the mail   
 >for that user afterwards.
   
 I'm hoping I'll have a chance to look at this soon, but in case anyone 
else looks at it first -- this is VERY LIKELY to be a WebCit problem, not 
a Citadel server problem.  
   
 It's probably saving the modified vCard in the Aide's own "My Citadel 
Config" room instead of the target user's "My Citadel Config" room.

[Citadel Development] (no subject)

2009-12-10 Thread IGnatius T Foobar

   
 Hey everyone,  
   
 Just wanted to mention that I'm sorry I haven't been immersed in Citadel 
development over the last couple of weeks.  I'm currently facing the 
double whammy of both being overwhelmingly busy at work *and* suddenly 
dealing with some personal issues (read elsewhere on Uncensored for that). 
 
   
 I'll jump back in with both feet soon, I promise.

[Citadel Development] (no subject)

2009-12-04 Thread IGnatius T Foobar

 >would it be reasonable to output the number of messages in the smtp   
 >outbout queue via the mrtg command?
   
 I don't see why not.  MRTG uses a very simple data format.

[Citadel Development] (no subject)

2009-12-01 Thread IGnatius T Foobar

CommonJS effort sets _javascript_ on path for world domination
CommonJS is a grassroots campaign to quickly produce standards and a standard library for _javascript_. Our man on the inside reports on JSConf Europe, where the effort to produce interoperable _javascript_ embeddings was evident.
By Kris Kowal | Last updated December 1, 2009 6:19 AM

This has been a big year for _javascript_. New, fast engines have tested their legs. Libraries have matured. With the ECMAScript 5 draft proposal, the language is growing. However, the language remains largely in exile, to only be used in Web browsers. This year has marked a resurgence of efforts to make _javascript_ useful outside the browser. This was patently obvious at this year's first European _javascript_ conference, jsconf.eu.
There have been a variety of _javascript_ platforms for programming outside the browser since 1996, starting with Netscape's server-side offerings. A system called Helma (best known in Austria) has been around almost as long. In 2007, AppJet provided a service (now discontinued) for creating and hosting server-side _javascript_ applications. Aptana offers an IDE for front-to-back _javascript_ Web applications called Jaxer. Through each generation of Web development, _javascript_ did not measure up against Perl, PHP, Python, Ruby, Java, or other alternatives for general-purpose programming.

Several things have changed. The creation, proliferation, and discovery of _javascript_-driven HTTP requests gave rise to highly interactive websites and applications. This drove the need for faster _javascript_ engines, which have since become available to every serious denizen of the Web and most of their unsuspecting extended family. Furthermore, these highly-interactive applications usually require significant programming both on the client and the server, much of which now overlaps. Particularly, the technique of Progressive Enhancement often requires a feature to be implemented both on the server—for initial rendering and the baseline user-experience—and on the client, for an enhanced experience.
_javascript_ has a couple more things going for it. _javascript_ is the only programming language that has ever shipped on every consumer computer, and it has done so for the last 10 years. In these post-QBasic times, HTML, CSS, and _javascript_ have become for every ungainly, bespectacled troglodyte the gateway from social exile to deeper social exile. More noteworthy is that a growing number of graphic designers who would never confess that they knew how to program will readily hack with jQuery. There are a lot of _javascript_ programmers. Also, despite its deplorable shortcomings, _javascript_ is cool and people like it.
So, what is holding _javascript_ back from world domination?

_javascript_ has no module system. To compose _javascript_ scripts, they must be either managed in HTML, concatenated, injected, or manually fetched and evaluated. There is no native facility for scope isolation or dependency management.
_javascript_ has no standard library. It has a browser API, dates, and math, but no file system API, much less an IO stream API or primordial types for binary data.
_javascript_ has no standard interfaces for things like Web servers or databases.
_javascript_ has no package management system that manages dependencies and automatically installs them, except JSAN (not to be confused with JSON), which falls short for scope isolation.

CommonJS (née ServerJS) is an initiative that began in January with a post by Kevin Dangoor to his blog and the founding of a mailing list. In his blog, Kevin outlined the above problems and called for server-side _javascript_ aficionados to band together, write some specs, and support interoperability on their respective platforms.
"[This] is not a technical problem," he wrote. "It's a matter of people getting together and making a decision to step forward and start building up something bigger and cooler together."
The call was answered.
One week later, with 224 members, and 653 messages posted, we knew Kevin had struck a nerve. It probably helped that Kevin was already known for creating the Python Turbo Gears framework, Paver, and is presently working on Mozilla's Bespin. The people behind Helma, Hannes Wallnofer and Chris Zumbrunn, showed up. Kris Zyp, of JSON extension fame, showed up with his _javascript_ persistent-object store project, Persevere. Ondrej Zara brought v8cgi to the drawing board. Ihab Awad brought Google's Caja. Wes Garland brought a Mozilla SpiderMonkey-based implementation to the table.
One month later, we had converged on a specification for module systems and interoperable modules. Now, there are over a dozen compliant implementations of CommonJS module loaders, and hundreds of compliant modules.
CommonJS is a growing collection of standards, including

Modules
Binary strings and buffers
Charset encodings
Binary, buffered, and textual input and output (io) streams
System pro

[Citadel Development] (no subject)

2009-11-30 Thread IGnatius T Foobar

I'd say that's a feature, not a bug.  And yes, it should do that, as long 
as the feed provider is using the same uuid's for both formats.  Already 
seen is already seen.  I think that's great, because it means you can 
switch feed formats without seeing duplicates.  
   
 If you want to run tests, go find the place where EUID's are generated, 
and prepend a different string for an Atom feed.  But, please don't check 
that code in.  Dupe-zapping agnostic of feed format is a nice feature.

[Citadel Development] release schedule

2009-11-29 Thread IGnatius T Foobar



Yes, we definitely need to get something out soon.

[Citadel Development] Re: Citadel commit log: revision 8086

2009-11-25 Thread IGnatius T Foobar

Our URL parser handles either one, but the '&' gets interpreted by Tidy as 
an error.

[Citadel Development] Re: Citadel commit log: revision 8076

2009-11-23 Thread IGnatius T Foobar

Ok, well you can do all the unit tests you want; the real test is whether 
Kontact still works.

[Citadel Development] Re: Citadel commit log: revision 8076

2009-11-23 Thread IGnatius T Foobar

How unrecognizable is the dav server going to be when I eventually get 
around to implementing CalDAV?

[Citadel Development] Re: threads, aboit and canceling

2009-11-21 Thread IGnatius T Foobar

Y'all are thinking too much.  The original thread manager was deliberately 
made simple, almost naive.  I don't see any need to ever reduce the size 
of the thread pool, and I certainly don't see any need to gracefully shut 
down anything other than the database.  Quite frankly, I think we should 
configure the shutdown function to just kill off any threads that don't 
exit on their own within a few seconds.

[Citadel Development] (no subject)

2009-11-20 Thread IGnatius T Foobar

 >If one adds an RSS feed, do we catch that? My impression was, that it   
 >needs a server restart to make it collected?
   
 No server restart required, but you still have to wait until the next 
time it runs.  The RSS aggregator and the POP3 aggregator are started in 
the same way.

[Citadel Development] (no subject)

 >in general blocking on shut down for blocked tcp/ip connections (for   
 >example) is another nail to the coffin for creating reliable backup   
 >strategies.   
   
 Here's a reliable backup strategy: if it doesn't shut down within 10-15 
seconds, "kill -9" the server.  We have a journaling database and it 
*will* recover.

[Citadel Development] (no subject)

Ok, I'm going to revert r8058 and we'll see if that fixes it.

[Citadel Development] (no subject)

Can we change it back?  And how did you get that nifty view with the rev 
numbers and names?

[Citadel Development] (no subject)

..and it crashed again.  What's going on here?  What changed?

[Citadel Development] (no subject)

Ok, Uncensored just crashed because it hit the abort() at threads.c:781.  
Why is there an abort() in our code?

[Citadel Development] Re: Citadel commit log: revision 8064

 >I most probably could use some hints on the duplicate detection, 
 >since it seems as if it doesn't work with the atom of freshmeat.. 
 
 It's quite simple: if there is a  field present, we prepend "rss/" 
to it, and hit the use table to determine whether it's a duplicate.  If 
there's no guid in the item itself, we make one up using and MD5 hash of 
the title and link.
   
   
 I'm also noticing now on Uncensored that the links are missing.

[Citadel Development] Citadel commit log: revision 8064



Hmm, was there some sort of change made to the RSS module other than the initial Atom support?  Some of our feeds reloaded and posted a lot of duplicates.

[Citadel Development] Citadel commit log: revision 8064



Ok, all done

[Citadel Development] Re: Ugh, what a mess

Hey, nothing ventured nothing gained, right?  Enjoy your development 
platform.

[Citadel Development] Re: Confirmed, svn webcit isn't compiling on 64-bit gentoo