Folders v.s. Tags
Flickr, Del.icio.us and gmail use a concept called "tags" or "labels" to organize images, bookmarks and email respectively. Create tags as you go, items can have mulitple tags giving you a cross index. Not a new concept, but an "advanced" one, for the general public.

sipXconfig uses the classic Folders everyone understands, but there are a couple of limitations I hate. You create folders first then add items. Items can only be in one folder.

So in sipXconfig's situation, if a admin is trying to manage 10,000 users and their phones clearly they need two things above all else:
Organize items so even someone who didn't setup the system can find things (drill down)
Allow admins to share settings between the items.

The only customer in the thousand item range has done what most admins would do, create 100 folders in preparation for settings that may need to be different. Like single-heirarchy systems, it's relatively straightforward, if not cumbersome, to find items by drilling thru nested folders, but it's hard to change how settings are shared between folders without major restructuring. In addition, restructuring may be in conflict with goal to organize items so they're easy to find.

sipXconfig as Tags provides a lot of flexiblity when applying settings. An admin can add phones to the system and tag them with as many qualifiers that match their need at the time Example tags: "sales experimental" or "downstairs lobby 340-ata" or "engineering george". Physical location, models, user or users audience.

Million dollar questions: if search is good enough, do you have provide users the ability to "drill-down" through items and would it confuse them that items may show up in multiple places. Is this a user issue or a presentation issue? Also, I hesitate using the word "tag" and would like to use "folder" but this may be trying to pass an old dog as a new pony and confuse everyone.

Writing out load, do both. Use folders, first, as a organizational mechanism. Folder names are unique across the system, items can only be in one folder. If an admin wants to attach additional "tags" to an item, they can do that w/o affecting it's folder heirarchy. Kinda like ruby language, single inheritence but has mixins. Best of both worlds, but not clear how to convey this concept even to the advanced admins. Of course, in agile terms, sipXconfig could just support folders for now but design in a way to leave opportunity for "tags" if/when there's a demand.
- posted by Unknown @ 7:59 PM 2 comments | permalink

 
XFire SOAP support is nice
Currently we're using Axis SOAP that comes w/JBOSS. We're moving away from JBoss and all the code written in JBoss so it's as good as time as any to seek alternatives. Using Spring has made me lazy. Create classes and interfaces for what I do and everything else is just configuration of what to do w/those interfaces. So XFire is all about that too, give it the interfaces and let it register it as SOAP service, generated the WSDL, and even generate the client stubs which I plan to use for testing right now. Real SOAP clients are in C++ and perl. I hope XFire plays nice with C's csoap library implementation and Perl's SOAP::Lite.

So in my business library project, neoconf, I don't have any SOAP library dependencies

interface MyService {
void String basicMethodWithBasicParams(String basic, int basicToo);
}

and it's not until my web project that I expose this interface in web.xml and myservice-xfire.xml and that contains no code.

NICE!

Took some doing to get XFire to build. Followed directions on website w/a little help from mailing list about maven issues, of which I know little about.

I am a bit worried about all the dependencies:
file="${wsdl4j.jar}"
file="${wsdl4j-qname.jar}"
file="${stax.jar}"
file="${stax-api.jar}"
file="${javamail.jar}"
file="${activation.jar}"
file="${yom.jar}"

for client
file="${xbean.jar}"
file="${velocity.jar}"

But worth the price, and can't complain I'm sure it make the library very capable by leveraging other libraries.
- posted by Unknown @ 1:28 PM 0 comments | permalink

 
JBOSS in anger, years after
Starting with sipXconfig 2.8, progess has been made towards porting existing codebase from JBoss and JSPs to Spring Framework, Tapestry and Hibernate (TapSprHib). It's not that JBoss is an inferior technology, it just doesn't meet sipXconfig requirements anymore. Here my current comparison
- Memory requirements
o 400MB RAM with JBoss - JBoss 4.0.1 currently starts at 320MB and can grow to 400MB shortly after running. It can grow even more depending on what you're doing
o 60MB RAM with TapSprHib, this will grow as more is code is ported and libraries evolve but should stay in 100MB ballpark
- Startup times
o 1 minute, 57 secs with JBoss. This has already come down from even longer startup times by disabling many services. It's possible a few more could be disabled
o 11 seconds with TapSprHib
- Installation/Deployment
o installing jboss from tarball requires many manual steps including:
- patching JBoss installation
- copying in certs.
- setting file system permissions properly
Binary (e.g. RPM) installation is easier but this has other issues
- maintenance of custom RPM for SIPfoundry
- availability on other distributions is limited or behind in versions
- either limits development to work on 1 copy at a time or complicates
develop environment
o none - embedded Jetty jar file with 1 embedded configuration file
- Download/HD requirements
- 60MB+ as separate download for JBoss
- 4MB as part of sipXconfig download. This is a total of Jetty, Tapestry and Spring jars. Hibernate not included because its required for both

From these numbers, JBOSS is better suited for high-end enterprise systems, not as a transparent, integrated, web admin tool. EJB 3.0 spec and subsequently JBoss is evolving in an encouraging direction but it may be too little and it's certainly too late for sipXconfig.
Damian and I have already ported roughly 20% when refactoring daling plans, gateway management, managed polycom phone support. Damian and I will take a similiar tactic for sipX 3.0. Unfortunately users won't see the fruits of our labor until JBoss can be removed entirely. I logged the remaining portions of the port in the sipXconfig bug database as tasks: XCF-293 through XCF-306. I roughly estimated 60 man days to port remaining portions.
- posted by Unknown @ 7:03 PM 0 comments | permalink

 
FireFox for WEB developement
WebDeveloper is an extremely useful FF extensions that help with WEB pages design, reverse engineering and specifically with testing CSS.

My favorite feature: you can get click on any item on the screen and see all CSS styling that influence its apperance (CSS->View Style Information)

You can hide the toolbar if you happen to use FF just for browsing.
- posted by Damian @ 7:27 AM 1 comments | permalink