On Wed, Jun 4, 2008 at 11:10 AM, Greg Smith (gregmsmi) <[EMAIL PROTECTED]> wrote: > I want to minimize the scope but I see feature creep coming so we better > plan for it in advance.
Me too. I also want to have a solid app with a long-term maintenance plan :-) Great to hear we aren'to far away... I will snip the many points of agreement, and focus on the interesting parts... >> - let users blog, tag, etc >> - let users mark entries as draft/public/etc >> - show user's blogs locally > GS - On these three: I want the blog hosted elsewhere. There will only > be two states for a blog post: draft (AKA stored local or maybe on XS) > and Posted (AKA done and sent to blog or sent to teacher for approval). As a user, when you are writing the blog entry you need to post and be able to see a preview and edit. That means that we cannot avoid input validation, formatting, etc. Also - we cannot avoid some user management, and database management, however simple. > Maybe that's three, Draft, Posted, and Pending approval. Once "Posted" > all posts will only available on the hosted blog. Perhaps a list of URLs > to previous posts can be stored for the user but the actual blog posts > themselves are only saved at blog hosted site. In any case, that has pushed us into a territory that means that we have to do a lot of the work that forms the core of what a blog is. That is why I am saying we cannot avoid it, and should be reusing an existing blog. If you want to do it the easiest way - take Moodle and customise its existing blog facility to support - teachers can "approve" - approved posts are pushed out to a public blog and you will have plenty of time to spare - which we can use to tweak moodle a bit :-) > I see we need a really good DB data design. I'm not sure that the > current team has that experience. If anyone out there wants to help with > that let me know ASAP. I can give you a hand if you first pick a good base to work from (hint, hint!) > The replication/queuing posts problem will be a tough one too. Is there > any core XS work planned to handle queuing HTTP or other traffic aimed > at the WAN? I'd like to pass the buck on that :-) but if nothing is > planned we can try something basic like "try three times then wait an > hour and repeat". You can try it on a cron, and if have an exponential backoff. HTTP is not a queuable protocol - though you could do it over SMTP :-) -- i would love to recommend SMTP but it makes things more complex at the remote service end... > I hope we come out of this project with a recipe and key decision points > for build any XS hosted Web App... My hopes are the same. That's why the first rule is: do not start developing new sw if you can avoid it. Pick the best preexisting candidate, configure, tweak, enhance, patch. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
