October 8th, 2006On this day in different years

mischief

Need caching and archiving

As libj ends up being more and more complicated, there needs to be a location set for a given journal that:

1. Keeps an archive of journal entries and comments.
2. Keeps a record of the journal's information--account, server, MD5 hash of password. Should probably never even have the password stored plaintext in the library. MD5 of password seems sufficient for all even halfway secure methods of authentication.
3. In this way, when things get friended or their security changed, etc, the archive will also be updated. This will allow any programs to do more intensive operations off of the archive instead of repeatedly requesting each and every single entry.
4. If this is libj specific instead of program specific, the different programs using libj will be able to use the same archive for their bizness. That means LJClone, LJBunker, and FriendAll will be able to use the archives to do their work.
5. Will need a sync function that will download all changes and update
6. Will need a function to get list of entries and comment ids.
7. Will need a read in entry from archive function. Will need a read in from archive comment function.

Possibly should be looking into an embedded database for this...

http://java-source.net/open-source…

However, flatfile might be preferrable--more easily accessible in case things go wrong.

If using database, should definitely make a "Convert to HTML" or something. Should probably do that anyway.

But a flatfile wouldn't be too complicated, either.

archivedir
--account.info
--posts
--comments
--userpics
--polls
mischief

Need new transport library

Apache XMLRPC isn't cutting it. I really need to be able to set cookies and use them while doing XMLRPC, and Apache's just isn't built for that. (There's a request for cookie support in the whole bug thing and it's marked as major, but I don't know if I want to wait that long.) I'm pretty sure a simpler approach would be just fine here. Furthermore, LJ's XMLRPC interface isn't as complete as the flat interface. XMLRPC also doesn't serve for the comments exporting interface. I think LJ's XMLRPC able to set console commands, which the flat can't do, but that's it. And SB's XMLRPC interface is just sad. And pathetic. So an additional class will need to be able to do the regular POST/GET stuff anyway. And it seems stupid to keep one library that's using one transport and then have to set up additional transports in order to do any flat things, which is inevitable.

This means:
* Will need to implement an XMLRPC interface class that can create XMLRPC requests and also receive them. Apache's strategies are a good starting line for that kind of behavior.
* Will need to pick an xml writer/parser and use it for the XMLRPC and other stuff like the comment exports.
* Will need to implement a class that takes care of all of the back and forth of sending pages to the server and receiving them back. It should be able to set cookies for the authentication, because doing all these challenge/responses over and over sucks ass.